Dual-track Sprint/Iteration Planning Recipe
source link: https://www.jpattonassociates.com/dual-track-sprint-planning/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
If you’re using a typical agile process like Scrum, you’ll break your work into Sprints or Iterations that usually range from 1-3 weeks. You’ll start each Sprint with a planning meeting. If your team is a product team engaged in both discovery and delivery, your planning session will need to account for both kinds of work. This recipe will give you a starting point.
Sprint/iteration planning recipe
Purpose: use a team planning session to set goals and plan work together as a team. The team owns its plan. It isn’t given to them.
Who: the core product team including the product owner/product manager and the few people the lead discovery and development for your team’s product.
How long: this is a continuous activity. You may spend a little bit of time every day or every couple days. Just be ready for the team planning meeting or it makes it challenging for everyone.
1. Choose delivery stories a cycle or two ahead
If you’re a product owner, meet routinely with your core product team to discuss the progress of the solutions underway. Choose the stories that you’d like to take on next to move those solutions closer to release.
2. Workshop/refine stories ahead of time
For those on the product team, make time to work together with team members ahead of the planning session. Dig into details, split larger stories, and consider multiple options. In my book User Story Mapping, look back to Mat Cropper’s story in Chapter 7. When I spoke with Mat, one of the things he most looked forward to was the series of short, half-hour ad-hoc story workshops he had us developers and testers get ready for planning.
3. Review discovery opportunities a day or so before planning
Since you learn something after every cycle of discovery validation, it’s hard to choose these too far ahead of time. It may be as simple as carrying forward the opportunities you’re working on the in the current development cycle.
Be ready to talk about the opportunities you’ll be exploring over the next sprint. Be ready to talk about your learning goals. And, be ready to discuss the amount of whole-team participation you’ll need. You’ll need to give the team an idea of how much help you’ll need for them in the coming cycle.
4. Invite the whole team
And any others whose help you might need during the upcoming development cycle. Hopefully your planning session is already on the calendar. It should be a routine workshop that follows the cycle-end review.
Who: the whole product team responsible for doing the work. Optionally anyone else that may work with the product team during the next cycle.
How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box you’re planning for.
1. Start by discussing the big goals
You’ve chosen some opportunities to move forward with discovery work and some stories to work on delivering. How do these opportunities and delivery stories help advance your product?
2. Review the discovery opportunities you’ll be engaged in and agree on the amount of team time needed
Review each opportunity – there should only be one or two. What are they? What’s the benefit for building them? What are the risks or assumptions you’ll be working to test? How might the team help in this effort. Agree on a time-box for team involvement. You’ll need to know how much team time you’ll be using for discovery to figure out how much development work you’ll be able to take on.
3. Review the stories you’ll be turning into deliverable software
Don’t go into extreme detail here – just enough to give everyone the big picture. Use lots of pictures. Bring in decisions that smaller groups made in story workshops.
4. Set a time-box for the delivery team to plan on their own
Remember, crowds don’t collaborate. And the people building and testing this software need to do some real thinking to create their recipes for building these stories. Give the team an hour or so to break into small groups and work together on the stories. If you’re a product owner, UI designer, or business analyst, stay close by. Observe if you like. But be ready to answer questions that’ll help them move fast.
5. In small groups, create a plan for each story
Work in small groups that include developers, testers, and anyone else that has work to do to turn the story into working software.
- Discuss your approach to building each bit of software. Write out development tasks that describe your plan. But remember that you likely can’t anticipate everything. Be open to identifying new tasks as the development cycle progresses.
- Discuss how long each bit of software is likely to take.
- As a development team, decide how many of these stories can be successfully completed in the delivery cycle. Don’t forget to consider holidays and days off.
6. Together, agree on the plan
At the end of the time-box, and after the team does their plan for each story, they’ll need to come back and share their plan. Not every detail, because that would be super-boring, even to them. But, what’s important is for the team to be clear about what they believe they can get done in the cycle. They should take this plan and their agreement seriously, especially if they want others to consider them reliable and predictable.
Agreeing may take a little time, especially if all the work that needs to be done won’t fit in the development time-box. It’s lucky you know some tricks for slicing stories down thinner. Try dialing back a story from better to just good enough. That should make it fit.
You’re done. In the past, we liked planning in the afternoon. We tried to finish a bit before quitting time. Then we’d celebrate by taking the rest of the day off. We showed up the next day refreshed and ready to start working on the plan we created together.
Aggregate valuable and interesting links.
Joyk means Joy of geeK