The GSD Gold Approach to Sprint Planning
Let’s quickly review the key ingredients and prep work we’ve discussed in previous chapters that prepare you for your first sprint planning session:
- Break the application into features or Epics
- Further break down Epics into smaller components or Story candidates
- Define your Minimum Viable Product or MVP
- Group MVP components that should be delivered together
- Prioritize MVP components for the first release
- Write and groom Stories as candidates for the first couple of sprints
If your team has focused its efforts on the first release and first couple of sprints, you should have the right Stories in your Backlog as candidates for sprint planning. To be sure, review the Stories in the Backlog with the Product Owner before the sprint planning meeting and verify the highest priority Stories are at the top of the Backlog.
The first sprint planning meeting should take about 90 minutes. All the team’s work to date has prepared them for this moment.
All GSD Gold Team members must attend sprint planning.
Here’s the agenda used by GSD Gold Teams for the first sprint planning meeting:
- Review the MVP, so the entire team remembers the bigger picture (10 minutes)
- Decide how many points to take in the first sprint (15 minutes)
- Read the top Stories in the Backlog that are candidates for the first sprint and make sure everyone understands the requirements (30 minutes)
- Select the Stories to be developed in the first sprint (15 minutes)
- Agree to a Definition of Done (20 minutes)
Review MVP and Candidate Stories
The entire team needs to understand the endgame. Taking the time to review the MVP and candidate Stories with the team ensures that everyone is on the same page, understands the requirements and that the Product Owner hasn’t missed any important facts that affect prioritization.
Insights can be missed when the not-as-technical team members prioritize the Backlog without a good understanding of the application development. This quick review gives the architect, tech lead and programmers the opportunity to provide input that could streamline development and increase velocity.
For example, maybe Component A should be completed before work can begin on Component C to minimize technical debt. In the Backlog, Stories related to Release 1 Component A are below those for Component C, so low that they may not make the cut for the first sprint. The Development Team could bring this to the attention of the Product Owner, who could re-prioritize the Backlog and reduce technical debt.
In agile, we don’t like dependencies, but in the real world, they exist and pose a risk.
How Many Story Points?
In Chapter 4 on Story Grooming, we suggested that an 8 point Story would take the entire sprint for a programmer and quality assurance tester to complete the Story. Using this rule of thumb, for the first sprint, the team should take in about 8 Story points per programmer.
So, if your team has 4 developers, 2 QA testers, a BSA, Product Owner and Scrum Master, the team should bring in 32 Story points. If there are 2 identical teams pulling from the same Backlog, each team will take in 32 points for a total of 64 points. The entire team should agree to the number of Story points and feel comfortable with the goal.
Another thing to consider is planned time off, holidays,etc. The number of Story points should be adjusted accordingly.
Select Stories for First Sprint
Since the team has already verified the Backlog to be in priority order, start at the top of the Backlog and go down the list of Stories until the team(s) take in the agreed to total number of points. If there are multiple teams, a programmer from each team alternatively pulls a Story for their team until their team pulls the max story points for their team..
Assign those Stories to the sprint and they now become part of the Sprint Backlog to be completed over the next 2 weeks.
Definition of Done
Before the team starts sprinting, they need to decide the rules around closing stories. The list of what the team expects to accomplish before a Story closes is called the Definition of Done (DoD) aka acceptance criteria.
We recommend including the following in your team’s Definition of Done (acceptance criteria):
- Review requirements with Product Owner and/or BSA
- Analysis and design documentation posted in story or team wiki or Sharepoint
- Automated tests in every program
- Quality assurance testing by QA team or another developer
- Pass code review
Classic agile dictates that the members of the Development Team demo their work for each other at the end of the sprint, during the Retrospective (Chapter 7). However, we’ve worked with several teams that like to demo their Story work as part of the Definition of Done, to immediately knowledge share and to ensure nothing was missed from a technical perspective before closing the Story. Present both options to the team when you write your Definition of Done. Let the team decide what works best to start.
Your team may also have other requirements, based on your own organization’s coding standards and PMO policies. Periodically revisit the Definition of Done to ensure the requirements adequately support your development process.
The Product Owner must accept the story before it can be closed. The Definition of Done becomes the standard by which the Product Owner can compare to determine whether or not the story is ready to be closed.
Congrats! You’ve officially kicked off your 1st sprint.
< Back to Chapter 4 Story Grooming —– Chapter 6 Sprinting >
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.