Scrum: Myths and Facts quiz

Not at all! The purpose of the daily scrum is for the developers to check how they are progressing towards the Sprint goal and (re)arrange their work accordingly and in a collaborative manner.

Not at all! The daily Scrum is an event for the developers of the Scrum team. Although the Scrum Master’s presence can be beneficial, he/she does not have to be there – he/she just need to make sure that this event is positive, productive and within the timebox.

Preferably not, this is an anti-pattern! The daily Scrum is for the developers to arrange their work for the day to progress towards the Sprint goal. If anyone else than the Scrum team members want to join this event, check for their motivations and see how they can be addressed in an efficient manner without disturbing the developers. In case their participation could be beneficial, the Scrum Master should check with the developers if this is possible and ensure that the event is not disturbed by this additional presence. 

In Scrum, all events are time-boxed, this means that an event should not go past its defined duration. The daily Scrum timebox is 15 minutes and it is therefore not fine for it to last more than this time. If this is your case, the following may help you: more often than not, the Developers are trying to solve issues within the daily Scrum. If this is the case, identify the related impediment and call for a meet after with the Developers who can actually solve it.

The Sprint planning answer three questions: why we are doing the Sprint (Sprint goal), what we will do for the Sprint (the selected backlog items) and how we will reach the Sprint goal (the plan). Those 3 elements create the Sprint backlog.

Not at all! Although this is by far the most common way of sizing items, the PBIs can be estimated in hours, T shirt size or any other unit of measure that the Developers may find fit. The Scrum Guide actually refers to sizing of items so you could also consider to do no estimate at all!

There are 3 parts to the Sprint backlog: the Sprint goal (why we are doing this Sprint), the Sprint Backlog Items (what we are doing) and the plan on how to reach the Sprint goal (how we will do it).

Not at all! Although this is a popular tool for measuring progress, the Scrum team can select whatever tool thy see fit. It could be burndown chart, burnup chart, Cumulative Flow Diagrams or any other thing that they see fit.

Not necessarily! Although this is considered a best practice and was previously a must in previous Scrum guide versions, the Scrum team decides when they want to address the most important improvements.

This can be a good practice in a beginner Scrum team but it is not mentioned in the latest Scrum guide version anymore. Developers can use what they see fit as long as the daily Scrum is productive and kept to its timebox.

Refining Product Backlog Items (PBIs) on a regular basis with the Scrum team is a good practice – hence the common reference to a product backlog refinement event. However, this is simply a practice which is not part of the Scrum event.

Yes, definitely! The Sprint Review should not be considered a gate in releasing value so if the stakeholders are eagerly waiting for an increment and it can be released, it should be done after checking with the Product Owner.

Yes, definitely! If not, you will have work of different Scrum teams which cannot be integrated as is as they have different level of quality and readiness. Multiple Scrum teams working on a common product are generally collectively responsible to bring an integrated Increment.

Not at all! The Definition of Done (DoD) is a key aspect of Scrum to create a shared understanding between its members of what done means. Without this artifact, members can end up arguing if an item is actually done or not and if it can be presented in the review and/or released to users.

Yes, those are:

• For Product Backlog, the Product Goal
• For Sprint Backlog, the Sprint Goal
• For an Increment, the Definition of Done

This is a recommended format but any other can be used as well as long as the Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. Members should also identifies the most helpful changes to improve the team’s effectiveness.

Not only! The Sprint retrospective is for the Scrum team to improve its way of working so Scrum Master AND Product Owner should attend and collaborate in this event.

Since the Scrum Guide 2020, there is only one team in Scrum and that is the Scrum team which comprises of the Product Owner, the Developers and the Scrum Master. Previous versions of Scrum called for two teams: the Scrum Team (same as above) and the Development Team (only made of Developers)

No. Although the definition of ready (DoR) is considered a best practice, it is not part of the Scrum Guide.

No. The Scrum Guide is very clear on this – only items meeting the definition of done can be demonstrated in the Sprint Review. This is to help manage stakeholder’s expectations.