In this issue:
Agile estimation. Nothing seems to bring more fervor to an argument than by pairing the words “agile” and “estimate.”
Well, controversy doesn't bother me. Here are three estimation traps I've seen in agile teams:
- An expert signs up for their own stories, thinking it will help the team's throughput.
- Your management wants the team to estimate it “all” before delivering anything.
- Someone (often a manager) thinks a velocity target should be a stretch estimate.
1. Experts sign up for stories.
Fred, and only Fred, takes all the internals of the search stories. That Fred doesn't present the results, which means the team needs two people to complete those stories. However, Fred says, “I'll take that and it's y time.”
He knows what to do and he's good at it. Here's the problem: only Fred knows the internals of search. What happens when Fred goes on vacation, or worse, gets the flu? And, Fred only does a part of the story; he still needs someone else to finish the feature for the user.
Many people think it's efficient for one person to work to reinforce their expertise. It can be efficient in the short term. However, narrow expertise reinforces silos on a team and doesn't help the team deliver features faster.
Agile approaches mean that the team delivers features, not each person's part of a feature. Instead of experts estimating “their” work and working alone stories, ask the team to work together, to pair, swarm, or mob. And, help the team realize they need to measure the team's throughput of completed stories, not any partially completed work.
Never let experts work alone. Their estimate might be shorter, but when teams don't create expertise across the team, their estimates become less reliable.
2. Estimate everything before delivering anything.
A powerful aspect of agile approaches is that we use small deliveries to verify we're on the right track with the product. We can change what the team works on often.
When someone in political power wants the team to estimate everything before the team delivers anything, they have this assumption:
We won't discover more useful features the team should deliver, before what we thought we wanted.
I often see this assumption when teams are not accustomed to delivering often, and when managers remember that it took months in the most recent project for the team to deliver something useful.
Keep the stories small and deliver something every day. You won't have to estimate “everything.” (You might not have to estimate anything if you can deliver every day!)
3. Velocity is a target the team should use as a stretch goal for their estimate.
In the previous Pragmatic Manager, See Your Agile Measurement Traps, I wrote about a classic misuse of velocity. This misuse is an agile schedule game.
Instead of playing the game, ask the manager these questions:
“What result do you want? Is there something you are looking for aside from completing the project as quickly as possible?”
You might discover some outcome your team can deliver, and fast.
Agile estimation works best when the team estimates together and delivers together, with any luck, every day.
This is the third in a series of trap emails in honor of Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. The previous two emails were about collaboration traps and measurement traps.
If you have trouble with estimation traps on your agile project, check out my newest book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. The book is available in ebook and print forms. I wrote the book so you can decide how to use an agile approach, for your team and your context.
Look for announcements about the Influential Agile Leader and more workshops in the next week or so.
Are you new to the Pragmatic Manager newsletter? See previous issues.
Till next time,
© 2018 Johanna Rothman
Tags: agile, Create Your Successful Agile Project, project management, trap