I think people like a good fight. Certainly the media seems to, as is evident in the world of politics, sports, and entertainment to name a few. In the world of business analysis the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Round One

Relative Sizing of User Stories (Scrum)

• Tee-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories (features or requirements) 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 tee-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 tee-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 (business representative) decide which user stories to prioritize for a release.
• Story points. We can then assign each tee-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 tee-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.

Relative Sizing of Projects, Phases, Deliverables, Tasks (Waterfall)

For years we have used 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 deliverables (such as a small, medium, or large report), I know of teams that have used them on the whole project, project phases and tasks. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk), as well as on the history.

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 always do so.

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 (but not the product owner) uses a special “deck of cards,” which can be an actual deck or pieces of paper. Each card has a number. 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 turn 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 the previous round. Again, they explain their rationale. This process continues until consensus is reached.

Traditional Planning Using Delphi

The Delphi technique involves a group of experts providing their estimates anonymously. Like planning, poker, there are rounds. The experts provide their estimates anonymously. A neutral party collects the estimates, shuffles them, and silently reveals them to everyone at the same time. No discussion is supposed to occur. Rounds continue until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the real power of Delphi is in the discussion of each person’s assumptions about the estimates, so as a project manager, I modified Delphi to allow discussions between rounds.

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. So while Scrum makes things easy and practical, the traditional Delphi, including its name, feels arcane.

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

Comments (10)

Subscribe to this comment's feed

...
written by a guest, May 19, 2010

I find it intriguing to see the reference and comparison between "waterfall" and "scrum". In the one context (waterfall) the reference is to that of a noun - based on a premise that a pre-defined framework, deliverables and work products exist. In the other context (agile/scrum) the reference is to that of a verb - the techniques that are used to increase the efficiency of the creating and maintaining the deliverables and work products.

We must always take caution when we begin to interchange how the noun and how the verb are to be applied.

• 
• -1
• 
• 

...
written by Andrew Procca, May 19, 2010

An interesting topic that has been on my mind lately. I would rephrase the challenge as 'Agile vs the world'.

I think you would probably consider me a project traditionalist, although I blend my planning techniques to suit the project. Since my projects involve a fair amount of technical risk, the closest model is rolling-wave.

What I am curious about is how well agile will work when you have to interface to hardware that is being created as part of the project - in which case software is just a sub-deliverable that is part of a larger hardware assembly.

In this case the principle of delivering completed functionality may not be possible since the interrelationships are more extensive than on a 'pure' software project. - Is my understanding of Agile principles correct?

In this case can Agile deliver a jab, right-hook or become just a useful in modeling a project as any other approach?

• 
• +0
• 
• 

...
written by Elizabeth Larson, May 20, 2010

Guest,
Thanks for your comment. I'm not sure I followed your concern. Having a master’s degree in English, I often struggle with the precision, tone, and formality I use in my blogs. In general I am l informal in my blogs and more formal in my articles. However, I went back through the blog in question and found two references to “Agile,” both used as adjectives describing “methods.” I found several uses of “Scrum,” some of which were used as an adjective (as in Scrum framework or Scrum processes), but mostly as an implied adjective, used as a stand-alone noun with the word “framework” implied. I couldn’t find either term, Agile or Scrum, used as a verb. So unless the published blog is different from the one I submitted, I can’t find the reference to verbs that you describe.

• 
• +0
• 
• 

...
written by Elizabeth Larson, May 20, 2010

Andrew, I share your concern. While I have certainly heard students and clients discuss success on large, highly-integrated Scrum projects, I have no actual experience managing such a project using Scrum. We did use RAD on a very large, integrated new system with a new technical architecture and many new business processes. The three tenets of RAD, Iteration, Increments, and Involvement (full-time business person on the project) were critical to its success. We did break this huge project into three large projects and then broke one of these into four even smaller projects. We could have delivered some very tiny pieces of functionality in 2-4 weeks apiece, but I struggle to think of how we could have done the whole project using Scrum without a tremendous amount of rework. But I hear it can be done!

• 
• +1
• 
• 

...
written by Cameron Watson, May 20, 2010

Elizabeth,

I appreciate you taking the time to respond - I suspect I may have misread or misinterpreted the article (noun, verb, adjective or otherwise). I guess I missed the "implied" part - now I am trying to understand the "implied" scrum/agile framework (in the context of a predefined set of deliverables- i.e. requirements definition deliverable or project charter deliverable or a testing strategy deliverable) and the work products/deliverables that will be the resultant of applying scrum/agile techniques. Hoping you might be able to point me to the scrum framework so that I can review the deliverables/work products that can be produced. Appreciate your patience.

• 
• +0
• 
• 

...
written by Elizabeth Larson, May 20, 2010

Guest,
Like the PMBOK® and BABOK® Guides, Scrum is a framework, not a methodology. As with any framework, the deliverables produced depend on the project at hand. Both bodies of knowledge explicitly state that it is important to choose the tools and techniques and produce outputs that make sense for the project. Having said that there are some deliverables (sometimes called artifacts) that are common on Scrum projects and which can be decomposed into a WBS. Estimating starting with the deliverable-based WBS will most likely be included in Round 2 of the Scrum vs. Waterfall fight. Hope that helps.

• 
• +0
• 
• 

...
written by Cameron Watson, May 20, 2010

Elizabeth,
I appreciate you taking the time to get back to me/us. For the record, although "guest" will suffice, my name is Cameron Watson - I am the President of QAIassist.

In seeing your article I could not help but try and make a contribution. The case in point is not about your article or its content, but rather, how it is possible for very senior (I suspect we may be able to claim we can collectively bring 50 years of experience and expertise with applying methodologies, frameworks, life-cycles) resources to have such varied and different perspective on specific terms and the contexts in which they are to be applied. A methodology to one is a framework to another, a life-cycle to one is a methodology to the other, a deliverable to one is an artifact to another. My concern is not that this difference of terminology will cause the world to stop turning, but rather, that the lack of consensus and agreement offers all practitioners an environment and latitude that enables and even fosters confusion and misconception. In having worked with so many project teams and resources throughout the years it still astonishes me when the majority of practitioners are not aware there is a difference between the "path" as a noun (person.place,thing - structured predefined set of phases, deliverables, work products, artifacts, etc) that is constant and used to arrive at the desired destination (completed project on time and within budget) versus the "path" as verb (action) in how the project team is to proceed (agile, scrum, RAD, waterfall) along that "path". As to the "scrum" versus "waterfall" discussion I believe the most prudent and effective thing deserving of the audience is to make an effort to establish the premise and terminology without assumption. Knowing the size of the ring, the tightness of the ropes, the number of rounds and the size of the gloves before anyone chimes the bell can only help every practitioner.

Looking forward to your response.

• 
• +0
• 
• 

...
written by Robert Galen, June 02, 2010

Elisabeth,

I love the context and framing of this blog post. I'm truly looking forward to your follow-on discussions. I hope the "fight" goes on for many rounds -- perhaps even to overtime ;-). Although, I'm not sure boxing allows for such things.

I would like to see you be clear though from a methodological perspective. Classic Scrum does not prescribe user stories or planning poker / relative sizing as part of the methodology. User Stories are derived from Extreme Programming as a "practice". The whole planning poker / relative sizing thing, as you say, has it's roots in (Wideband) Delphi techniques -- which pre-date the agile methods by quite a bit. Mike Cohn is the guy to be blamed for refocusing them in an agile context under the Planning Poker moniker ;-).

While both these techniques are widely used in Scrum contexts, they're not part of Scrum. One can have PBI (Product Backlog Items) that are simply sentences and not sized at all, and still leverage the Scrum framework quite nicely.

That emphasizes my bigger point, to make the distinction between Scrum as a very simple, Agile Project Management framework and the many practices that might be used in conjunction with it. I think it's important for non- and newbie-agilists reading this blog to understand the distinction. I know, I know, probably a nit, but perhaps an important one.

Beyond that though, please keep fighting the good fight ;-) Thanks for this!
Bob.

• 
• +0
• 
• 

...
written by David Donaldson, June 02, 2010

I am curious as to the arena this fight is being held in? Are we talking SW development projects or something more concrete like building construction? The reason I ask is that it is my understanding that Agile is a SW development methodology (as stated in the manifesto) so to compare waterfall in the SW arena there should be a clear advantage to Agile… however, if we were to move to a building arena, say a project to build a new 60,000 seat boxing arena I think that waterfall would be a better choice. That said, there would likely be the opportunities to use Agile in places, where appropriate.

I think the advantage of Agile when you are on a project that is in a virtual world where we do not have to tear down physical structures to make changes later in the project life. So I am seeing these not as competing rivals but complimentary team mates with diverse skill sets who’s advantages will shine based on the situation.

I am looking forward to round 2 - ding ding!

• 
• +0
• 
• 

...
written by Elizabeth Larson, June 06, 2010

Bob,
Thanks for your thoughtful comment. I always enjoy your blogs. I suppose we all have our own nits. One of mine is the distinction between a methodology and a framework. A framework, of course, allows the use of various tools and techniques, such as the two planning techniques alluded to in my blog. I certainly did not mean to imply that the Scrum framework owns these techniques—far from it, since they’ve been used on projects since I started estimating (and that’s a very, very long time). Having said that, if I communicated that techniques such as user stories, Delphi, and relative sizing were unique to Scrum or even a part of the framework, rather than helpful tools, I certainly did not get my idea across effectively! Thanks for helping to clarify.

• 
• +0
• 
•