Where are you on your kanban journey? Are you looking for ways to optimize your processes or have some concerns? Or simply want to check if the way you organise work is the way it’s meant to be. If so, this article has several things that can help. It focuses on estimation methods but also looks at how they affect our understanding of what an epic, a story and a task mean – creating clarity about them helps us roughly estimate pretty well.
The main part of this article provides useful tips on how to estimate tasks quickly with kanban without burdening teams with unnecessary overhead involved in traditional planning poker sessions. They’re based on my experience as someone who facilitated quite a lot of planning poker sessions during sprint planning meetings. I’ll describe two alternative ways of estimating tasks which are basically guesswork and some rules of thumb. Though not as precise as planning poker, both these methods are precise enough to estimate backlog items quickly. I’ll also show you what makes them effective.
Finally, I will offer a third technique for estimating tasks – the Story Mapping approach. First presented by Jeff Patton, it’s gaining popularity among Agile teams who aim to deliver valuable software working products early and often. I won’t go into much detail about how it works since there are already articles that describe this very well (see sources at the end of the article). I’ll briefly explain its benefit for saving time during estimation sessions instead. Here goes!
Estimating time required for completing work is not an easy task. It involves the following factors:
The experience of your team in doing similar tasks in the past which serves as a reference point The number of people involved in completing the task Task complexity How much you know about it at this point when estimating Effort needed for testing and fixing bugs (which we don’t factor into our estimates) Risk
– there’s always something that can go wrong and affect timely completion (risk) Complexity of any integrations we must deal with, etc. Other “unknown” variables that we’ll never be able to predict or control by estimation alone (weather, moon phase on the day of release, etc.)
– Waiting for competitors to release their game before you release yours
– The publisher standing over your shoulder
– Resources being tied up elsewhere – Was the task already estimated at some point? If so, what was the estimate and how was it arrived at? Did estimates change since then? Why did they change (i.e. assumption changed, more information, etc.)? Is there a gap between previous estimates and our current one that needs to be explained or addressed? Are all tasks fully scoped out yet, or are some still in progress? Are estimates for remaining tasks accurate based on the last part of the tasks that have been completed thus far? These are just a few questions that may arise during estimation . It’s not about getting an exact number down to 2 decimal points. It’s about estimating so that the estimate is in line with reality .
For this purpose, we’ll take a look at the most basic of tasks: Bug Triage. If you’ve never heard of bug triage before, it’s when developers go through the list of open bugs in their product and assess them to determine if they are duplicates, valid, work items or not an actual problem. Then they can get rid of invalid data from the system which makes everyone else’s lives easier because there is less clutter to sort through. A great idea for any agile project but more on that later.
Let’s assume you work for an application development company and your customer has asked you to look at the current bug list to determine if there are any duplicates or invalid data . You know that it is important to provide them with an accurate estimate of how much time you believe it will take to complete this task. Let’s also say that your triage process takes 10 minutes per item.
Using Wrike, I found a relatively simple workflow that calculates the number of days based on estimates in hours. It works by creating a new subtask for each bug report where the person must enter how many hours they think the task should take. Once all people have given their initial estimate, someone can go through and recalculate a more precise number by taking the average of all initial estimates.
You can access my configuration at the bottom of this blog post and it would probably be fairly simple to modify it for your workflow if needed. However, I didn’t feel like modifying mine so I built a different solution instead. My new workflow allows people to enter their hour estimate in a subtask description, which is then automatically converted into days when the issue is created in Wrike. But let’s walk through how this is achieved starting with how Wrike calculates time tracking based on estimates .
