Several sub-tasks are needed for proper sprint grooming. They are essential steps in crafting a sprint plan. These tasks are not trivial and include such on-going difficulties as estimating the time or effort required. In this episode, we will look closer at these essential activities.
Estimating Effort
There is no end to the content available to assist us in estimating effort. However, there is also no silver bullet that allows us to guarantee proper estimation. That is not a blocking issue. We will get better at estimating as we do it more often. Perfection is not needed. We do want to be as consistent as possible and be able to get close to our estimates. This task is not for driving effort or accountability as much as it is to provide a metric for velocity. We want to be able to say how many estimate points we typically tackle in a sprint.
Effort Sizing
Sprint grooming is when we select items to place in a sprint. Therefore, we need to have a rough idea of the number of points we can implement per sprint. We also need to have items in the backlog that have point values far lower than our velocity.
Even better, we should be able to tackle one or two tickets per developer per day, where possible. This approach gives us a comfortable granularity for progress and allows a dev team member to feel like they have accomplished something every day. Break larger tickets into smaller and more manageable parts where reasonable.
Load Up The Sprint
It is important to remember that the goal of sprint grooming is not fully loading up the dev team. There are non-implementation items like meetings and planning that will cut into a full load. We also want to allow for some buffer in case an item is under-estimated. A safe target seems to be around 75-80%. A sample breakdown of this can be seen in this article.
Task Life-cycle
The last thing we review in this episode is the complexity around the life-cycle of a task. This process is often biased or defined by the way the team works and ticket granularity. For example, you might have a test status for a ticket, or testing can be a different ticket. Every team needs to define this process and how tickets flow. However, the details involved are specific to each team. Therefore, note that life-cycle needs to be defined. Do not assume that what works in one team works for another.
Challenge of The Week: How do you create (and estimate) tickets? What obstacles need to be removed?
