Estimating in Agile delivery
What are the challenges with estimation in Agile?
One of the first things I learnt when I went through the Scrum Master Course was Planning Poker. I thought this was fun, a different way to estimate and very engaging. I brought it back to my team and they loved it.
But the Steer Co and PMO still wanted estimates. They still want to know how long it would take to build the features for the project and how much it will cost.
We went through this planning poker process and then I would try to convert the story points into some idea of days and effort. Talk about an anti-pattern!!
That was over 10 years ago. Teams and projects still go through this pain. I don’t think you can discuss agile estimation without including the organisational context.
If organisations have a process of estimating duration and costs and having funding approved based on that, how does agile estimation fit in?
I don’t think it can.
I think that is where agile delivery breakdown. Organisational frameworks don’t support agile delivery.
What’s the solution?
Unfortunately, it’s not going to be simple.
SAFe and LeSS try to solve this challenge.
As Scrum masters, project managers or team leads, those questions are beyond our scope. We need to get the teams to estimate and plan the work.
For the following few newsletters, I’ll be discussing the various estimation techniques that agile teams can use to plan the work. I’ll also be covering the question around organisational practices to support agile estimation.
Affinity estimation
Affinity estimation is another way to estimate in an agile framework.
It’s a quick and easy way of estimating. It’s really useful for teams who have to estimate a large number of stories (greater than 20).
It doesn’t remove the need to do more granular sizing.
It doesn’t remove the challenge of subjectivity. One team member’s small may be another’s medium.
It also doesn’t remove the indirect influence of senior experience team members skewing the sizing.
Scenarios, where Affinity estimation can play a role, would be:
during release planning or during pre-PI where stories can be sized into buckets;
during delivery when new stories have been identified and need to be quickly sized.
How to do Affinity Estimation?
The team attends the session.
Each team member gets a subset of the product backlog
On a wall, you have a scale set up - small on one end and extra large on the other
Each team member silently, without discussion or consultation, starts putting their backlog item on the wall on where they think it sits in the scale.
The product owner is available at the back for any questions
Any items that can’t be sized are put on a pile to be dealt with later
Consider the work that needs to be done to develop/ create and implement that backlog item
The next step is to edit the wall, team members review the items and in discussion with each other, will move the backlog items around to the agreed position on the wall.
Team members need to be mindful of the initial sizing and consult the team member before moving the items to another part of the board.
POs take note of discussions and any gaps or additional stories that need to be identified.
Put the backlog items into agreed sizing buckets. The team need to agree beforehand on what the sizes mean. Any disagreements are discussed and negotiated by the PO.
Based on discussions from this action, there are several next steps that can be taken. Below isn’t an exhaustive list.
Create additional stories to close the gaps identified.
Refinement of the stories to make it more granular.
Spike to verify some outcome.
Have you tried Affinity estimation? What’s your experience with it? What would you do differently? Leave a comment, I’d love to hear from you.
Quote
“A key tenet of agile estimating and planning is that we estimate size but derive duration.”
― Mike Cohn, Agile Estimating and Planning
Do you make a distinction between the two - size and duration - when your team estimates and plan the release?
If you don’t, what will happen when you do next time the team estimate and plan? How will the approach change?
I’ll be interested to hear your comments on this. Please drop me a note.
Practice
For your next set of new user stories or backlog items, use the affinity estimation process.
What did you find out? Anything improved? Did anything didn’t work out?
Leave a comment below to share your experience.
Interesting Resources
Another classic book on Agile delivery. One of the first books I got in my agile journey.
The Poppendiecks apply lean principles to software development. The implementation of those principles uses agile practices. It identifies waste in delivery and what teams can do to remove it.
It’s still a book that I refer to regularly and it’s one that I re-read often.
Products to help you
Below are digital products that I have created for you to help improve your craft.
Remember - regular practice improves your mastery.