Recognize Estimation Traps

Watch for these schedule games or estimation traps:

  • The team thinks experts who “sign up” for their own stories will help the team’s throughput.

  • Managers misunderstand the idea of velocity and use it as a target for the team to achieve.

  • Sometimes the team thinks it can do more—with no data behind that thinking.

  • Your organization wants your team to estimate the entire project before it starts delivering value.

You have options for managing these traps.

Trap: Experts Take Their Own Stories

Especially when teams start with agile approaches, they realize that they have specific expertise. Janet knows about the database schema; Dan knows about the middleware; Sharon knows the UI; and Steve can test anything you throw at him. The team finds it tempting to estimate as individuals and then to assign stories based on expertise.

When experts work alone, the team creates WIP, often substantial WIP. Instead of the team collaborating, swarming around one story at a time, each person tries to make progress alone. However, the people on the team need each other to make progress.

The problem is that the team can’t release features unless people collaborate. At the very least, a developer and a tester need to collaborate to finish a feature. Many teams have barely enough testers, so when experts take their own story, the team creates queues of work, delaying all the stories.

Consider these options:

When experts take their own story, they optimize for a single person and busyness. When team members take stories together, they optimize for working as a team and delivering results.

Trap: Double Your Velocity

This trap arises when someone—often a manager or project manager who doesn’t understand agile—wants to improve the team’s output. This is a classic misuse of velocity as a measurement.

Velocity is a way for teams to use their historic information to predict what they might be able to do for the next iteration. This is a way for teams to avoid a total SWAG (scientific wild tush guess) for their prediction.

Velocity is not a productivity metric for the team—or worse—for the individual. See ​Velocity Is a Capacity Measurement​.

Here’s cynical answer #1: If you want to increase your velocity, the fastest and easiest way is to double the number of points you assign to your stories; that will double your velocity. It doesn’t change how many stories you actually finish in an iteration, but it will look like you’ve doubled your velocity.

Cynical answer #2: If you want to alleviate the pressure from someone, you can play this game, too. You can divide the stories into two parts: Story Part 1 and Story Part 2. With any luck, you are dividing your stories along reasonable lines so that you see business value from each part. If not, well, the stories are still small enough that you finish them quickly. You can also double the points for each part. You can recurse on this trick almost indefinitely.

Of course, when you randomly split stories like this you’re not splitting your stories so they help you deliver business value more often, which is what you really want to do when you split stories. But you are playing schedule games.

Now, here’s the real answer: To break this trap, ask your manager this question: “What result do you want? Is there something you are looking for aside from completing the project as quickly as possible?”

Explain that in agile approaches, you ask the team to work at a sustainable pace, providing business value frequently to stakeholders and asking for feedback. The team works at the best pace for it. The team doesn’t move slowly by design—the team works hard. The team might encounter spaghetti code, or code and tests that haven’t been refactored, or code that appears to have side effects with no supporting tests. The team isn’t going slowly on purpose—it’s working at a pace that allows it to proceed without making big mistakes. What is the manager looking for?

In addition, remind the manager that team velocity is personal to a team, as hair color or eye color is to a person. As soon as you change team members, the velocity is likely to change. If you change the product domain, the velocity could change. It’s a measure of past behavior that is likely to predict future behavior. It’s not a guarantee.

Instead of showing anyone velocity, consider showing any of the measurements in Chapter 14, ​Report Your Project State​.

Trap: We Can Do More

The team has created a stable velocity of 35 points per iteration. In some iterations it can finish 37 points. In other iterations, it finishes 32 points. But as an average over the past six months, it finishes 35 points.

Someone thinks the team can and should do more. The team needs a “stretch” goal or some such nonsense.

Stretch goals don’t belong in estimates. They don’t belong on agile teams, because the team’s velocity is based on a sustainable pace.

When teams create accurate estimates and meet those estimates, they understand how to work together and maintain their sustainable pace. Such teams maintain focus and code quality. They have the flexibility to refactor the code and tests as they proceed, to create the best product possible. These teams are not under stress to do “more” when that “more” is an unreasonable request.

If anyone on the team wants to try more points per iteration, help that person see his or her data now. Consider asking how this person will create an experiment. See what happens. Maybe this team member can do more if the stories are smaller.

On the other hand, if someone outside the team wants the team to do more, explain that velocity is not acceleration. If this person wants the team to do more, the only way is to reduce the story size (not create tasks, but reduce the story size) so the team increases its throughput.

Trap: We Need Detailed Estimates for “All” of It

Sometimes the product owner thinks the team must estimate the entire feature set even though the feature set is large and the team will deliver the features incrementally. (This is related to, but is the estimation side of, ​Trap: We Can’t Release Anything Until It’s “All” Done​.)

The larger the feature set, the more difficult it is to estimate all of it. Combine that with the ideas that the stories might change, and your team has a recipe for potential estimation disaster.

Consider these options:

  • As a leader, have a conversation with the product owner and ask that person what she or he needs. Is the product owner under pressure to provide a detailed or specific delivery date for that entire feature set? If so, ask if the team can work on only that feature set until it’s complete. Consider asking the team to swarm or mob on the first several features in the feature set so the team can learn as it proceeds.

  • Measure the cycle time for each feature as the team proceeds. It’s possible the later stories will take less time, but I have not always seen that.

  • Remind the people pressuring the team for the large estimate that the larger the thing the team estimates and the farther out that work is, the less accurate the estimate will be. Ask what these people want. They might want delivery as fast as possible. In that case, work with the product owner to make the stories as small as possible, and ask the product owner to rank all the stories in this feature set higher than any other story.

  • Create smaller deliverables, and demo them to the people who want the estimate for “all” of it. This shows the team and the person who wants the estimate how the team is proceeding.

Consider using the graph Expected Value Over Time, ​here​, to help the product owner (or the people pressuring the product owner) to assess value over the entire feature set. It’s possible the customers want the first few features now but could wait longer for other features.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset