By Elizabeth Larson, PMP, CBAP, PMI-PBA, CSM
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. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”
Part 1: Estimating
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 User Stories (Scrum)
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 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 One – Scrum wins, but its 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.
Become
a Watermark Learning Member for Up-to-Date Industry Info & Free Resources
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 Two – Scrum wins, but again, its 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.
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.
Part 2: The Fight Continues
Part 2 explores both the similarities and differences. Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.
Similarities
There are many ways in which these two approaches are similar.
Both:
- Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
- Stress the importance of communications.
- Allow for more or less rigor as appropriate.
- Find communications easier when the teams are collocated.
- Both face more challenges with virtual teams.
- Have processes to manage the scope.
- Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.
Differences
Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of “breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.
Intricate, large projects
On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.
Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum of Scrums or other processes, but I have found that following a plan is a stress-reliever.
Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.
The Winner: Waterfall!
Defining requirements when they are highly volatile
Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.
Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.
The Winner: Scrum!
Managing scope and changes
On Waterfall projects schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.
I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects.
The Winner: Scrum!
I could go on with this comparison, but I’ll simply list out areas where I think Waterfall wins and address them in more detail in the future.
.
Waterfall wins in these areas:
- Effectively using the role of the BA to define requirements completely using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
- Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
- Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.
Of course Scrum wins in some other areas, too...