Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

Demystifying Use Case Modeling

Written by Elizabeth Larson on . Posted in Articles.

demystifyingusecase1We all know how difficult it is to achieve project success without complete product requirements. Yet gathering complete requirements without exhausting the project schedule and budget remains elusive for many project managers. In this short article we will provide tips for gathering hidden requirements quickly.

Traditionally, many software developers have embraced new technology. As flat files gave way to hierarchical databases and as those databases gave way to relational tables, as mainframe technology became distributed and as object oriented technology replaced information engineering, many developers jumped at the opportunity to learn new skills. Project managers, however, tended to be more wary. How this new technology would affect schedules and budgets, what the relationship would be between the technology and project risk and quality, how easy it would be to hire staff with technical expertise became tough questions for these managers to answer.

With new technology came new methods known as development methodologies. We went from the Waterfall methodology to the Whale model, to Rapid Application Development to Iterative Project Management, and each new process claimed to reduce the software development cycle time. Each has had both advantages and disadvantages, but none has proven totally satisfactory. One reason for the disillusion is that none addresses gathering and managing requirements both quickly and thoroughly.

One proven approach for quick and complete requirements-gathering is what I call “concurrent modeling.” This approach is different from concurrent component engineering, or concurrency, commonly used in developing e-solutions. Concurrent modeling suggests that by modeling business data, business processes, system processes through use case modeling, and prototyping, requirements quickly surface. In addition, each type of modeling effort supports the other modeling efforts and forces analysts to ask their customers the kinds of pertinent questions that drive out hidden requirements.

While modeling requirements with use cases does not provide a complete solution, it does provide one important dimension of requirements-gathering-that of describing the conversation between a system and its user(s). Although this system is usually automated (such as an Order system), it can be a system in its broadest sense, comprised of methods, procedures, forms, and automated systems. Another way to think of a use case is that it describes what a system does in response to a request or a trigger. If I want my car to stop, I need to have a ‘conversation’ with it and make that request. Today I need to talk my car’s language; I cannot simply shout ‘STOP!’ I need to use an interface to state my request. That interface is the brake. Hopefully the car responds by slowing down and coming to a halt.

Use cases have their roots in Information Engineering, which twenty years ago had such proponents as Ed Yourdon and James Martin. What we then called event or process modeling, we now call use case modeling. External agents became what we now call actors. Data flowing into and out of the system and processes within the system, we now think of in terms of interfaces. We now call the hierarchy of system processes use cases.

Many practitioners confuse this system process model with a business process model, or process map. Both use cases and process maps describe processes. The former describes the reaction of a system to an external trigger. Process maps also describe processes, but from the perspective of who does what in the organization. In both cases the process is described with one verb and one noun, known as an action and an object, and in both instances inputs are transformed into outputs.

An example of a process is ‘Check Inventory.’ From a business process perspective, checking inventory might include a business person examining actual items, perhaps taking a physical count of the inventory, scanning cartons or items, and comparing the items on-hand to a report. In use cases modeling ‘Check Inventory’ might describe how an Order system (actor) queries the Inventory Management System to see if the requested items are in stock and then reserves the items, all without human interaction.

One of the most commonly asked questions from my students is why they need to do modeling other than use case modeling. I answer as follows:

  • Data models provide what information appears on user interfaces (UIs), for both data entry screens, as well as reports. It also provides many of the business rules, e.g., whether or not customers are required to have accounts.
  • Process maps provide UI navigation, which should follow the business processes (hopefully improved or reengineered). These maps also drive out business rules, e.g., we process deposits before withdrawals.
  • Prototyping, which is derived from both the data and the process models, allows for early feedback and helps drive out additional requirements.
  • Use case models not only show system interfaces, but can lead to a description of edits and messages and testing scripts. They also become the basis for software program design.

It’s no wonder, then, that one of the most common complaints from so many people is that they have done a thorough job of use case modeling and yet requirements still surface throughout and after the project!

So to help achieve success on software projects, focus not just on the project effort, but on the product requirements. And remember that concurrent modeling will reduce the risk of schedule and budget overruns, since hidden requirements will surface sooner in the development process, reducing the cost of rework during the entire project and, importantly, after the project is implemented.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Is the Business Analyst a Product Owner or Tester on Agile Projects?

Written by Elizabeth Larson on . Posted in Articles.

There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That’s not to say that someone with the title of BA cannot play other roles as well. It’s just that when they are playing these other roles, they are not doing business analysis work.

BA as Product Owner.

The role of the product owner is essentially that of the business subject matter expert (SME). Their main accountability on the project is to articulate the vision and define and prioritize product requirements. Their role, as the sponsor’s key delegate, is to make business decisions. The BA has accountability to both the business and the project. On the one hand BAs need to ensure that the end product or service meets the business objectives, and that the requirements are defined completely and correctly. However, they also need to ensure that the end product or service meets the project objectives and that it is delivered within the project constraints. Finally and maybe most importantly, BAs are not decision-makers. They are facilitators, consultants and, hopefully, trusted advisors.

BAs as Testers.

Testing on Agile projects is an essential role. While theoretically the delivery team wears multiple hats, one of which would be that of tester, practically speaking I have seen more instances where outside testers fulfill this role. With the wide-spread use of automated testing tools on many agile projects, it is helpful to pay attention to testing on its own with its own resource(s) devoted to it. It seems to me that, as with any approach, separating both business analysis and testing from development work, makes a great deal of sense.

BAs as BAs.

So where do BAs most effectively fit into an agile project. BAs are most effective doing BA work, but the work needs to be done just-in-time.[1] Here are just a few ways the BA can support the agile project:

  1. Help the sponsor and product owner define and articulate the business problem and product vision
  2. Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops
  3. Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they’re done. These criteria need to be more complete than, for example, “the order has been placed.” I have found that creating specific criterion tends to be difficult for product owners.
  4. Trace user stories to business objectives and the product vision and throughout the sprint to ensure it’s actually been delivered as imagined.
  5. Model the “as-is” and “to-be” business processes.
  6. Model the expected system interactions, particularly when software is being developed.
  7. Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution.
  8. Create mock-ups of the new user interfaces.
  9. Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions.
  10. Assess how ready the organization is to accept the change.

“Grooming” the Backlog.

So how can BA do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks? By ensuring requirements are defined completely and correctly before each sprint begins. The BA can work with the product owner and other business and technical SMES as the delivery team completes each sprint. However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

While many organizations use the term “agile” to mean doing things in a quick and dirty way without adding a layer of business analysis bureaucracy, others have considered the consequences of omitting the role of the BA and are now recognizing the vital role BAs can play.

[1] In the 2010 survey, The State of Business Analysis in Agile IT Practices, participants indicate that “requirements for Agile projects should be immediately consumable by IT project teams. 72% of companies surveyed indicated that requirements should consist of process flows (or visual use cases) or visual story boards in lieu of only textual lists and paragraphs. Requirements that include visual assets (such as business process diagrams, use cases, user interface mock-ups, and data relationships) require less interpretation from project teams and are more accurately leveraged for project direction” (Executive summary p. 4 http://www.requirements.net/2010/06/30/now-available-the-state-of-business-analysis-in-agile-it-projects-survey-report/)

Don’t forget to leave your comments below

Seven Success Factors for Requirements Planning

Written by Elizabeth Larson on . Posted in Articles.

KSFIf care isn’t given to planning the activities of defining product requirements, the entire project could go awry. It is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects.[1] There are many success factors that can relate to projects, products, and processes. Some apply to all three. For example, time taken to clarify roles and responsibilities helps ensure that all stakeholders know their accountabilities. Without a clear definition, it is almost certain that not only will tasks remain undone, but that those involved will be unhappy. Since stakeholders are involved in projects, in defining product requirements, in implementing new products, and in completing business processes, defining roles and responsibilities applies to all.

Here are some other examples of common success factors:

  1. Collaboration
    Regardless of whether we are working on projects, products, or processes, we work with other people. Collaborating, establishing partnerships, and using our networks in and outside of our organization help us face challenges and problems when they arise. We’ll find that others are more willing to help us through difficulties. When we implement a new project, product, or process, it is important to obtain agreement from those affected. Without this buy-in, the affected stakeholders may sabotage our efforts, intentionally or unintentionally.
  2. Clearly Articulated Benefits
    All stakeholders involved need to have a clear understanding of what they are trying to accomplish and why. They need a clear sense of direction, and also an understanding of how their work contributes to the health and well-being of the organization.
  3. Managed Scope
    Scope applies to projects, product requirements, and processes. The project and product scope are intertwined, since the scope of the product requirements affects the scope of the project. The project scope includes the entire effort to produce and implement the end product. Developing a prototype of a new bridge (product), for example, will usually take less effort (project) than creating and building the bridge itself. The scope of a process also needs to be managed. All processes begin and end, which are their boundaries or scope.
  4. Process Scope
    This intertwines with the other two types in that the relative process scope size will affect how large a project is to work on it, and the product deliverables that are produced. As an example, if the project is to create software for a retail store point of sale application, it will be larger if it includes the process of Returns in addition to just the process of New Sales transactions.
  5. Clear Communications
    Communication that sends the intended message in its entirety is meant to clarify, and if direct and unambiguous promotes success in work on projects, product requirements, and processes. Incomplete, unclear, or dishonest communications are some of the easiest ways to ensure conflict, as stakeholders struggle to make sense of what information they have received.
  6. Asking the Right Questions
    Whether working on projects, product requirements, or processes, we will encounter things that need clarification. When we don’t understand such things as a requirement, a task, or a process step, we know to ask for clarification. However, sometimes we assume that the sender and receiver of the message have a common understanding when, in fact, they do not. We call this having different “mental models,” or mind pictures. On product definition, for example, a common reason requirements change is because we think we understand the business need, when really our mental picture is quite different from our clients.’ Because differing mental models can cause a great deal of rework on projects, products, and processes, it is important to ask clarifying questions.
  7. Adequate but not Burdensome Documentation.
    No matter how good our memories are, we sometimes forget important things.
    • Project. Agreements, deliverables, milestones, and risks plans are required on projects of all sizes.
    • Product. A list of requirements and/or appropriate models, plus a method for ensuring that approved requirements have been implemented, are important for most business analysis work. Although the amount of formality varies from project to project, the need for the appropriate amount of documentation exists.
    • Process. The documented process of who performs the work, what steps they will take, where the process begins and ends, initial inputs, and final outputs are included in the process documentation that is needed to ensure repeatability. Of course, too much documentation can be demoralizing and costly.

Common Success Factors for Projects, Products, and Processes – Seven “Cs”

  1. Clarify roles and responsibilities
  2. Collaboration
  3. Clearly articulated benefits
  4. Crisp and managed scope
  5. Clear communications
  6. Crucial questions
  7. Critical documentation: adequate, not burdensome.

In summary, projects can easily struggle and fail for many reasons. Not taking care of requirements and failing to plan are major contributors to failed projects. By following our seven “Cs” of planning, you can help your projects achieve greater success, run smoother, and result in happier customers. The success factors apply equally to other facets of work, such as with project and product planning, and will help beyond requirements planning.

The preceding is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning, written by the authors of this article.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com) For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK). Their book, Practitioner’s Guide to Requirements Management, Part I: Requirements Planning is available through Amazon.com. For more information, contact them at 800-646-9362, or at www.WatermarkLearning.com.

[1] Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

Scrum vs. Waterfall Round 2; The Fight Continues

Written by Elizabeth Larson on . Posted in Articles.

scrumvswaterfall1Last month we began our “fight” by exploring two estimating techniques that are often used on both Scrum and Waterfall projects (view here). The first was relative sizing (one kind of analogous estimating) and the second Delphi (called Planning Poker in Scrum). Scrum won both rounds (barely) because, although both techniques can be used on both types of projects, their usage in Scrum seems easier to understand, learn, and apply. I don’t know about you, but when I hear the terms Analogous and Delphi I think academics and hard work. When I hear about tee-shirt sizes and planning poker, I think fun.

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore 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:

  1. Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
  2. Stress the importance of communications.
  3. Allow for more or less rigor, as appropriate.
  4. Find communications easier when the teams are co-located.
  5. Both face more challenges with virtual teams.
  6. Have processes to manage the scope.
  7. 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 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 my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

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. More later!

Don’t forget to leave your comments below

A Heavyweight Fight; Scrum vs. Waterfall

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on A Heavyweight Fight; Scrum vs. Waterfall

heavyweight1I 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…

Don’t forget to leave your comments below