Round One

Relative sizing of user stories (Scrum)

• T-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a T-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a T-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the Product Owner decide which user stories to prioritize for a release.
• Story points. We can then assign each T-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1,2,3,5,8,13,21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the T-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Waterfall relative sizing of projects, phases, deliverables, tasks.

For years we have used use relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on projects and deliverables (such as a small, medium, or large report), I know of teams that have used them on phases and tasks as well. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk).

Round 1—Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not.

Round Two

Scrum Planning Using Delphi (Planning Poker®)

 Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (not the Product Owner) is given a deck of cards, each card with a number. For example, if using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1,2,3,5,8,13,21, etc.) going as high as desired. The Product Owner explains the details of the user story and at the count of three team members turn over the card with the points they think most appropriate. For example, two team members have turned over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from last time. Again, they explain their rationale. This process continues until consensus is reached.

Traditional projects using Delphi,

The Delphi technique involves a group of experts providing their estimates anonymously. Like Planning Poker, there are rounds. Although this can be done electronically, the experts usually write their estimates on a piece of paper.  A neutral party takes the estimates, shuffles them, and reveals them to everyone at the same time. No discussion is supposed to occur. For the next round and based on seeing the estimates of the others, each expert provides a written estimate which can be the same or different from the previous round. The process continues until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the power of Delphi is in the discussion of each person’s assumptions about the estimates.

Round 2—Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through Planning Poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand Planning Poker. I have seen teams take to this technique immediately. But while Scrum makes things easy and practical, the traditional Delphi feels arcane. In addition, the traditional approach has some points taken off for having to use experts and for the required anonymity.

So, the current score is two zip. But the match is not over. Much more to come…

A Heavyweight Fight–Scrum vs. Waterfall: Estimating Part 1 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I have always thought of business analysis as the most ambiguous and the most fun of the project phases. However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. As a business analyst I thought it was project management work. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience.  So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are four tips.

1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small. It’s easier to estimate a user story than an epic story, or one specific business process than business process modeling in general.
2. Choose your approach. We’ll estimate differently if we’re using a plan-driven approach (Waterfall) than if we’re estimating in a change-driven (Agile) environment.
3. Use a variety of estimating techniques. On many projects we cannot be precise about our estimates when we’re first asked how long business analysis will take. We usually use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes four hours to model a business process and we have five processes to model, it will take twenty hours to model business processes.
4. Brainstorm.  Talk with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
5. Identify all the deliverables/artifacts.  Make sure you know your deliverables before attempting to identify the tasks needed to produce them.  Here are a few examples of deliverables: user stories, agendas and minutes, “as-is” business process model, traceability matrix, to name a few.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was communicate our status regularly, rather than surprising him after months of effort. What a lesson learned!

Five Tips for Estimating Requirements was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog