-
Notifications
You must be signed in to change notification settings - Fork 5
Pre Planning
Preparation for Planning
- Break down design work into Issues
- Review Issues in Ready column on Kanban board
- Prioritize Issues in Ready column on Kanban board
Thursdays at 16:00 (EDT -04:00)
- Review ToDo list from previous Planning meeting
- Verify Issue is complete
- Review Todo from previous Planning meeting
- What is the definition of done for a card in the Ready column?
- Complete instructions, design assets, labels, milestones
- Understand priorities: Start with a conversation about issues to complete in the next iteration.
- Review designs: Discuss each feature and make sure everyone is aligned and has what they need to proceed.
- Size the work: When the designs are understood, work out what needs to be done to complete these issues.
- Review and Commit: Get agreement on what can realistically be delivered and who is committed to each issue.
Open by explaining the goal for the iteration. Present insights and assumptions and how each issue supports this goal. Prioritize risks and identify dependencies.
Ask questions and look for opportunities to break user stories down further. When stories are small with clear story tests, they’re easier to estimate and more likely to be delivered.
Have designers present each feature and discuss the considerations to keep in mind when developing the feature.
Take some time to dig into the details required to test each issue, agree on what done looks like and estimate how long we think each issue with take.
For large issues, which will take more than a couple of days to implement, decompose the work into tasks: small pieces of work that contribute to the delivery of a user story (a few hours or work, not more than a day). Doing this can sometimes reveal more tests and ways to split the issues down even further.
There’s another benefit in breaking the work down into tasks. Small tasks make it easier for the team to share the work and coordinate efforts so multiple people can work on the issue.
When stuck, ask questions like these:
- How are we going to test this?
- Do we need anything from other teams?
- Is there anything else we need to do to meet our definition of “done”?
Once agreeing on what needs to be done, estimate how long the issues will take to complete. Do this collaboratively, without deciding who will work on which tasks at this stage. Consider the work to be done without padding the estimates to allow for things to go wrong. Even if some days there seems to be one interruption after another, it’s just not possible to estimate interruptions.
Estimating is not making a wild guess. If we really have no idea about how long it will take, do not jump into estimating and instead take time to explore what needs to be done.
If a longer investigation is needed, plan a spike. A spike is a timed investigation with the goal of producing an estimate. Once we have a better understanding of the work involved, we can consider the story for the next iteration.
The simplest approach is to discuss each issue and then agree on an estimate. As each issue is estimated, the estimate is marked on the GitHub card.
The next part of planning is grouping the issues into an iteration schedule the team can realistically deliver. This is often the hardest part because usually some trade-offs have to be made.
Once estimating is done, we need to understand our capacity and plan an achievable number of issues to deliver. After running a couple of iterations, we will have some velocity data showing how much we are delivering per iteration.
Take care not to overload. If knowledge bottlenecks are a consistent problem for the team, encourage plan in learning tasks to broaden the skills of the team.
Prioritize issue cards in the order the we plan to work on them. Put the highest-priority ones at the top unless there are risks, dependencies, or deadlines associated with particular cards.
For the issues each person has committed to they should add themselves as the Assignee. Cards should not be pulled into Development until they are actively being worked on.
Snapshot the planned issues along with the estimates. At the end of the iteration, compare this historic data with the velocity actually achieved.
- Create an agenda with the team for planning meetings, possibly breaking planning into more than one session. Use the agenda in the meeting to refocus conversations when they drift.
- Remind the team to work with the Dragons before planning meetings to prepare issues.
- Make sure everyone has an opportunity during Planning to ask questions about the experiments.
- Encourage design discussions before estimating the work.
- Do a task breakdown for large issues. Tasks can be added to the card along with the stories during the iteration to help coordinate work.
- Work at a sustainable pace and do not make promises that velocity shows we are unlikely to keep. Check capacity before making the final cut of what issues should be in the plan.
- Before the meeting breaks take note of what is planned along with the initial estimates so we have a baseline to use when calculating velocity.