Accounting for Planning, Retro, and Review time in the sprint
My team does sprint planning on the first day of the sprint and we are working toward doing the review and retrospective on the last day. How do you account for the time these activities take as it relates to your burndown?
For example, my team will put their daily capacity to 4 hours per day (full time for us) and then we'll task our sprint work. As we add hours to our tasks, we look to fill each team member's capacity. But that capacity doesn't include the 2-4 hours it takes to sprint plan nor the 1-2 hours it takes to do a review and retrospective, which equal out to at least one day's worth of work per engineer. How do we capture this time so we don't actually go over capacity?
How about stop worrying so much about the actual hours and filling each team member's capacity? Focus instead on whether the Sprint Goals are being achieved and the value of the increment that is made available to stakeholders for feedback. Scrum is not a task management method. It is not a time tracking tool. It is a framework designed to foster the incremental delivery of usable increments of product value that is focused on goals set for each Sprint.
Let me ask you some questions about your current methods. How do you account for the 3 hour estimated task that ends up taking 12 hours because not all information was known when the original estimate was made? How do you account for the 8 hour estimated task that ends up taking 30 minutes because not all information was known when the original estimate was made? How do you account for that one team member who experiences a medical emergency on the 3rd day of the Sprint and will not be available for the remainder of the Sprint?
Anytime you try to "manage" capacity you are ignoring the basic principles of agile software delivery. Focus should be on the teams ability to consistently deliver usable increments of valuable product updates. Not the hours of work by each individual that were needed to do so. During Sprint Planning, after establishing a Sprint Goal the Developers use estimates to help them determine if they feel the work selected to satisfy the Sprint Goal can be completed during the Sprint time box. Once they agree on that, there is no need for capacity because they are focused on delivering work that satisfies the Sprint Goal.
Burndown charts are not meant to show hours/capacity. They are meant to work completion. When a unit of work is completed, the burn down chart will reflect its completion by lower the remaining units of defined work. That is because you can never know how much time will be needed to complete something until the work is completed. "Burning" estimates really provides no benefit at all. You might benefit from reflecting how many tasks are completed and what remains undone but even that depends on the people that use the information and how they use it.
Are you using task hours at all in your planning then? Or do you have teams write their tasks, give a gut-check on if the work is do-able within the sprint timebox, then start working?
I've always had my team assign hours to tasks and typically everything washes out in the end -- something estimated as 4 hours takes 30 minutes and vice versa. But we've always tried to fill our capacity. Maybe that is where the problem lies.
But we've always tried to fill our capacity. Maybe that is where the problem lies.
Exactly, complex work cannot be planned perfectly. Expect unknowns and other things that will disrupt the plan. Hence the Developers have a Daily Scrum to replan their work for the next 24 hours. Planning to 100% capacity is not a wise choice with complex work such as software development.
@Daniel has given some good advice around focusing more on the Sprint Goal and done Increment.
I'll add a few more thoughts on Sprint burndown charts - they are intended to be used by the Developers to understand the work remaining in a Sprint. A Scrum Master may teach the Developers about it but should have no real use for it. The Y axis doesn't have to show task hours, it could show the number of PBIs, story points, or even the number of tasks remaining.
Some teams find work item aging charts and CFDs more useful.
Tasking is also optional, as is putting hours on tasks. I haven't seen many teams put tasks on hours in the last decade, as it adds extra overhead to Sprint Planning. They've learned that it is better to get to work and learn rather than worry about task hours.
Like anything else if the tasks, hours, and burndowns help the team consistently meet their Sprint Goal and produce a Done Increment every Sprint, who am I to judge?
My team does sprint planning on the first day of the sprint and we are working toward doing the review and retrospective on the last day. How do you account for the time these activities take as it relates to your burndown?
These activities are not part of their forecast of work for meeting their Sprint Goal commitment. So why would the Developers need to account for them in the way you describe?