Agile estimations: how we defined our own best practice
Have you ever struggled to understand how to estimate tasks in an agile project? When you finally understood, was it difficult for you to explain it to someone else how it works?
The first challenge comes when you become a part of an agile team. This understanding is usually not complete until you work for some time with each other, fail a few times, adjust to the rhythm. Then it kinda blends in your regular work and becomes natural.
The next challenge comes when you need to educate somebody new how estimations work and how your team estimates tasks (user stories, backlog items, whatever you call them). For example, somebody joins the team with little or no agile experience, or you work for a client and understanding of agile philosophy on their side is not shared across the organization.
On one of the previous projects we had a mix of both. Also, we had multiple teams of a similar setup, but different estimation approaches (and therefore different velocities) which sometimes raised questions about the efficiency of each team from the client.
So we wanted to find a way how to quickly explain to anybody inside and outside of the team how do we estimate. Something that combines a theoretical background and our practical experience in the team.
What is Effort? What is Complexity?
While many agile guidelines offered to include effort and complexity in the estimation of a task, over numerous conversations we found out that people understand these terms differently. Some even include one into another and vice versa. If you ask random people on the project to define effort or complexity, you won’t get identical results. That was one of the key points to work on for us — bring everybody on the same page in terms of terminology. This was supposed to make any explanations more straightforward. So we agreed on the following:
Instead of Effort and Complexity, we would use Amount of actions and Difficulty
Usually, estimation is not an exact evaluation, but a comparison of one item of work over another. The terminology simplification allowed us to grade those terms and put some comparative qualities to them. This gradation is something the team is doing during every estimation discussion. We just put it to words and ended up with:
High, medium, low amount of actions
Easy, medium, hard level of difficulty
Now mix and match
To visualize how we can use those comparative qualities together we put them in a simple matrix. Such type of matrices are frequently used for risk management purposes, but some teams adapt them for estimations as well.
On a given project we used story points for estimations. So in every cell we put a number of story points that we would give to a work item.
Taking into account team velocity during each sprint we highlighted 3 types of zones: green, yellow, red. They would guide us on a planning session — whether it’s fine to take such an item into the sprint or we need to consider other factors.
When we shared this matrix with other teams and project stakeholders, it appeared to be quite easy to understand and follow.
As a hint during refinement or planning sessions we printed out a few copies and put on our physical boards and in meeting rooms.
From then on when anybody struggled with estimations, we could easily refer to this matrix and find the right fit for a work item.
Could this work for you? What tricks have you used to make your agile estimations better?
We are ACTUM Digital and this piece was written by Nick Lamonov, Agile Project Manager of Apollo Division. Feel free to get in touch.
