Sprint Backlog (scrum sprint,sprint backlog scrum,scrum backlog,sprint product backlog)
Impediments to Planning
As described in other chapters, the scrum master may need to organise meetings to co-ordinate the stakeholder and product owner if this is not happening as necessary. This is not a must for the scrum master and only happens if lack of requirements is an impediment for the scrum team. Prior to planning them, the product owner’s decisions should be translated into user stories with acceptance criteria and prioritized into the backlog. At this point, the backlog may be complete, but in order for any of its stories to be ready for a sprint planning session, we need to ask the question, “Does the team have everything it needs to complete this story?†There are often identifiable dependences such as third party feeds, specification documents or points of contact that need to be supplied in order for a team to do its job. The best way to know if a story is ready for planning is to be aware of what the team’s roles are and do everything possible to keep them focussed on their role. E.g. a software developer should be spending as much time as possible developing software as opposed to contacting third parties for specifications, a tester should be checking for quality instead of waiting for third party software to come in. These are examples of impediments for the scrum master. A product owner will need to do as much research as possible to prevent these situations arising for the scrum master.
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
Sprint Pre-Planning
There are often situations where background discussion is necessary to keep the scrum time-boxes running smoothly. For example, the scrum master and product owner should work hard to make sure that the sprint planning meeting is not the place to find out that a user story is not ready for the team, or that acceptance criteria is too vague. Do not get me wrong, sometimes this is unavoidable, since nobody thinks like a team of experts. However, confusion should be avoided wherever possible.
For these reasons, I recommend that a product backlog grooming meeting is held each sprint and optionally before each sprint where necessary a preparation meeting take place. Here the scrum master (organiser and facilitator) product owner and tester gather to review the proposed sprint backlog. The product owner presents the backlog, the scrum master usually has enough technical knowledge to know if stories are ready for the team, the tester knows if the acceptance criteria will meet entry-level requirements. It is optional to include other members of the team (I have often involved one expert from each field such as designer, developer etc.) I usually time-box this meeting strictly to one hour and I have found that the one hour saves the team far more than an hour of delay or confusion in a planning meeting. The team will likely thank you for it (and may even hug you), especially if they have experienced uncertainty in planning before.
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
