Mike’s class was an absolute necessity if you want to succeed with agile. While I will try to divulge a few key points from our class, nothing compares to actually being there, asking questions, and participating in real world exercises. Mike is a true leader in the agile realm and has real world experience behind his theories on estimation. So, here it goes, my brain dump on the class:
5 Words to take from Mike Cohn’s class on Agile Estimating and Planning (in his words):
As Mike said, he wants his courses to have just a few memorable words so it is easier to remember the content when referring to it later.
Estimate Size / Drive Duration:
Size -> Calculation -> Duration
Say you have 300KG story, your current velocity is 20KG per sprint, 300KG / 20KG = 15 sprints to tackle that 300KG story.
(300 KG -> Velocity = 20 KG -> 300KG / 20 KG = 15 sprints)
Topics on “How to Estimate”
The most important thing to remember is to estimate the size of a backlog item relative to the other estimates in the backlog. The bigness of a task is influenced by how hard it is, and how much of it there is. Basic math properties should hold (e.g. 5+5 =10).
Remember that humans are good at one order of magnitude (we really can’t accurately tell the difference between a 10 and 80, but we can a 3 to a 5 or 2 to 8).
While estimating, gut feel is important. It is a good reasonableness check, but we don’t want to solely rely on it. More often than not, gut feel is more accurate than the time/effort spent on trying to be accurate.
- Estimate by comparing user stories to others (this story is like that story, so its estimate is what that story’s estimate was)
- Don’t use single gold standard
- Triangulate (compare the story being estimated to multiple other stories)
How much effort do you use to estimate? Remember that a little effort helps a lot, but a lot of effort only helps a little more.
Topics on “What Makes a Good Plan”
One that supports reliable decision-making
A good plan will go from
- We’ll be done in the 3rd quarter
- to we’ll be done in August
- to we’ll be done August 18th
“It is better to be roughly right than precisely wrong” – John Maynard Keynes
It is nearly criminal to give an inaccurate estimate and almost as criminal to be precision based.
What makes planning agile?
Is more focused on planning than on the plan (value is in the discussion, not the paper hanging on the wall)
Results in plans that are easily changed
Is spread throughout the project
How to estimate velocity:
- Use historical values (if you have them)
- Don’t until you have run a sprint or two
- Forecast it by having the team plan 2-3 sprints and see what they come up with
Put a range around velocity estimates (add these % to your final estimate):
- Known team, domain, technology (+5%, -10%)
- Middle of the road (+10%, -25%)
- Unknown team, domain, technology (+25%, -50%)