From #estwaste to #NoEstimates - true story
Henri Karhatsu
What is #NoEstimates?
Method, process,..?
What is #NoEstimates?
"Just" a hashtag for estimation related discussion - Why do we estimate? Is there something wrong with it? Are there better ways? ...
"We are uncovering better ways of developing
software by doing it and helping others do it." (Agile Manifesto)
#NoEstimates = do as before + stop estimating
?
No need to estimate (#NoEstimates) ~ continuous deployment
TDD, build process automation, automated high-level testing, culture change, etc. enable continuous deployment
Why did our team stop estimating and how did that happen?
A long story begins...
Me: Scrum Master
Scrum Team: 10 developers + 1 tester
Company: Big corporation
First sprint observations
Long-lasting sprint planning meetings (5-7 hours)
Stories as given
Team members create tasks and estimate them by hours
One Tool to rule them all; One Tool to find them;
One Tool to bring them all; And in the darkness bind them
Team has one tester who is quite separate from the developers
"Nothing" to test during the first week
The other team finished 1 story completely, the other one none
(Surely lot of tasks were done)
Lot of #estwaste - not much results
10 members x 6 hours/sprint x 22 sprints/year
= 1320 hours/year
50 EUR/h: 66,000 EUR/year
100 EUR/h: 132,000 EUR/year
Retrospectives - great place to start a change
Renewed sprint planning:
Away from the meeting rooms
Whiteboard and post-its over electronic tool and paper printing
Developers write tasks by hand in small groups
Small groups present their thoughts for the others
Tasks are not estimated at all
Estimation technique: story points
What is the smallest story?
1 point
How many times bigger is this story?
1/2/3/5/8/13/21 points
From 1 to 5, how confident are you that you can completely finish all of these stories?
Sprint planning finished in 3 hours
Just changing how to plan isn't enough
Smaller stories
Start testing earlier
=> Faster cycle time
=> Stories are finished earlier
=> Better burndown chart
After couple of months - Scrum by the book
Long-term sprint/release planning with story points
Results from retrospectives
Scrum works nicely
End of the presentation?
How about continuous improvement?
Still waste in estimation process
Is this story 1 or 2 points? Who cares!
Should we estimate bugs? Should we count points when a bug is fixed?
"Let's reserve 5 points for the (unknown) task X"
"Velocity is in essence a negative metric – it can tell you that something is wrong, but not that something is good."
If our average velocity is 30 points, should we target to 60 points?
If our commitment was 30 points and we finished 30 points, was it a successful sprint?
If our commitment was 30 points and we finished 20 points, was the sprint failure?
Team had learned valuable lessons
1. Stories with 8 or 13 points are way too big
2. The smaller stories we do, faster we can get them ready
3. Sprint commitments had become reliable
Let's forget story points - let's use S/M/L instead
S = 1-3 points => OK
M = 5 points => are you sure?
L = 8+ points => split!
Commitment not based on velocity but on what the team believes they can finish:
From 1 to 5, how confident are you..?
Also sprint goal over point tracking
Sprint backlog can live based on the goal
The following sprints: all stories were of size S
Typical duration for a sprint planning meeting: 0.5-1.5 h
S/M/L as a proof of concept that we were quite ready to stop estimating
The biggest impediment at that time...
Two businesses, one dev team - Problems in prioritization
Split to two teams - Two backlogs - Easier to prioritize
No more sprints
No more sprint estimation (hours/days/points/SML)
Focus on the most important things
But how to know what is important if there is no sprint planning?
1-hour weekly meeting - sales, marketing, devs, etc.
Tell past actions and current status
Share new information
Discuss
Prioritize together
No estimates -> No I -> No ROI -> Bad prioritization?
What is our short-term business goal?
For example: we need more registered users
How to get more registered users?
From different options we should try the solution A first
Very autonomous and self-organizing development team
The proposed solution and the goal in their mind
Is this user story necessary? Can we leave it out? Can we actually find even a better solution?
What could be the Minimum Marketable Feature?
From a big solution A to small steps
Each step adding value even if the whole solution would never be built
#NoEstimates: Focus on R over I. Don't bite too big chunks.
What if you still need to consider big chunks?
Case: rather big refactoring in order to be able to implement important new features
12 tasks ("user stories")
When could it be ready?
Weekly throughput (story count)
instead of velocity (story points)
Forecasting based on actual data
(Instead of estimating days or arbitrary story points)
Was it ready as forecasted?
Yes, but...
MMF was half of the tasks we initially created
At the same time we also finished some other tasks
Throughput as expected but with different, more valuable, content
Autumn 2013
Development team consisted of three members
Release every two weeks (full of stuff)
Time spent on estimating: 0
So what was this story all about?
How to do #NoEstimates?
Or how to get better and work smarter?
You need to find your own path.
Do it with small steps. Continuously improving.
