Chapter 5. The New Way to Collect and Document Requirements

This chapter focuses on the front end of the Agile process, where customer and market feedback are incorporated into meaningful requirements. It addresses terms and ideas such as user stories, epics, acceptance criteria, understanding and measuring business value, prioritization, roadmaps, and Lean software development.

To best explain this concept, we start with Scrum and dive into how requirements are gathered—or elicited—and documented. Once that foundation is presented, we layer on the other methodologies and their unique traits.

In Scrum, the requirements are called user stories. A user story, by definition, must be small enough that it can be designed, coded, and tested within the sprint or iteration. Since the length of a sprint or iteration is short—two to four weeks—that forces our user stories to be simple and concise.

What exactly is a user story?

• What: A user story is a description of the requested feature (or component of a feature) that is short and simple.

• Who: A user story incorporates the perspective of the person who will use or benefit from the requested feature.

• Why: A user story incorporates the “value” of the feature so the team can understand what is driving this particular request.

• When: The user story will not actually specify a time frame, but there is a concept of time based on the prioritization of the user story: Those that are more time sensitive, or that drive more business value, are prioritized to the top of the list.

As a <type of user>, I want <some goal>, so that <some reason>.

These data points are all significant and helpful; each allows the product owner to express an element about the request, and it invites dialogue and collaboration with the developers.

• As a <type of user> = why is this significant? It is important for developers to understand the perspective of the user who will be taking advantage of the code. You might design a feature far differently if you know that the end user is highly sophisticated versus one who is technically challenged.

• I want <some goal> = this part of the user story expresses what the user is trying to accomplish: I want to be able to log in. I want to be able to reset my password. I want to be able to run a report. Understanding the feature request is critical to delivering the right thing.

• So that <some reason> = this is perhaps the most critical part of the user story format. Understanding why the user wants to accomplish something can be very enlightening to the goal just described.

For example, a request came in to Cayman Design that a web site administrator for our weather application wants to be able to run reports every 15 minutes. The developers would then try to figure out how to load new data and create a script to produce reports with very quick turnaround. But when the reason is added (so that) . . . so the web site administrator would have the chance to see when the application is approaching a threshold that will slow down the system. Now the developers have more information, and they might suggest a different way to solve that need, such as setting a threshold alarm that proactively sends notification if volumes get within a certain level of tolerance. Because what the user wants is a way to be notified of a possible problem, they do not really want reports every 15 minutes; they just did not see another way to solve the problem.

Let’s look at another example:

As a concerned and retired grandmother, I want to receive weather alerts for areas where my children and grandchildren live so I know when I need to worry and call them to make sure they are safe.

This is a pretty good user story. You know the Who = an older woman. Does this matter? Absolutely. You can assume that the user might not be as familiar with technology options so she needs a simplified user interface. She might even have failing eyesight, so perhaps she needs bigger buttons and a bigger font. It might even influence your color choice. The What = grandma wants to receive alerts about possible weather events in specific parts of the country; that makes sense and is easy to understand. The Why is also very important: She wants the alerts so she knows when to worry (and not) and so she can reach out to her family when she thinks they might be in danger. Is that relevant? Absolutely. Because knowing that she wants to know when to worry, the product owner and the team can deprioritize any messaging about stable, uneventful weather patterns. This user story is specifically looking for dangerous weather events—tornadoes, hurricanes, flooding, blizzards—that are occurring in particular locations in the country.

The Who, the What, and the Why create a powerful combination so that the team has much more to go on than the traditional way of documenting requirements. Another valuable aspect about the user story format is that it invites conversation or negotiation: Let’s talk about grandma, and discuss the best way to solve her problem. It is no longer a situation where the product owner has to know everything and provide irrefutable documentation of a desired feature. Now the team and the product owner are going to work together to find the best way to meet the needs expressed in the story.

Roman Pichler, an Agile expert on the role of the product owner, states it this way:

A user story is not a specification, but a communication and collaboration tool. Stories should not be handed off to the development team but be complemented by a conversation (2010a).

When it comes to writing good user stories, an acronym was first mentioned in 2003 by Bill Wake, and it still is used today when measuring user story effectiveness.

Product owners need to INVEST in a good user story.

• Independent—The user story must be able to stand alone. It must be a feature or a component of a feature that can be tested and implemented as a unique element. To the extent possible, user stories should not be dependent on other activities. Ideally, they are written so that they can be delivered in any order (Cohn 2004, loc. 646).

• Negotiable—As mentioned, a user story should invite collaboration and discussion about the best way to solve the business problem that is presented. The team, the Scrum master, and the product owner must be open to conversation about available options.

• Valuable—The reason why we do anything in Agile is to drive business value, and the more business value being delivered, the higher the priority of the story. If the story does not add business value, the team should not work on it.

• Estimatable—Is story too big or too vague? It must be clear enough that the developers and testers can reasonably estimate the complexity and length of time to deliver.

• Small—The story should be small enough to be completed within a single sprint or iteration.

• Testable—It is enough of a feature, and it is written in such a way that it can be tested to make sure it works as expected.

Mike Cohn introduced the concept of a “product backlog iceberg” (see Figure 5.1) when it comes to epics, and the iceberg suggests that stories need to be broken down into great detail only as you get closer to pulling them into a sprint (Cohn 2010, p. 244).

If a user story, or feature, will not be addressed for three to six months, then it is perfectly fine for that story to sit in the backlog as an epic. As time passes, and the opportunity to work on that story gets closer, the product owner and the Scrum master need to start breaking down that epic into the child user stories. By the time you get to the Sprint planning meeting, as described in Chapter 6, “Grooming and Planning,” no story should still be an epic.

The best way to understand epics is to look at an example.

“As a host, I want to make a Thanksgiving dinner, so that my guests think I’m a good cook.” This is a pretty good user story. You know the Who (the host or hostess), the desired What (make a Thanksgiving dinner), and the Why (want to be seen as a good cook). Thanksgiving is a US holiday that takes place on the fourth Thursday in November. If it is March, then having a Thanksgiving story in epic form is perfectly fine; it will take a while before we will actively work on it, so there is no business driver to force us to break that epic user story down into child user stories just yet. But as October arrives, we should start looking at the epic and breaking it down. Here are just a few examples of child stories that might come from our Thanksgiving epic.

“As a host, I want to bake a pie, so that my guests have dessert.” This is a good child user story. Of course, the host needs to do some baking so that the guests will think he or she is a good cook. This user story is much smaller than hosting the entire dinner and can probably be executed on in a single sprint. If the team decided that they wanted to make the crust first and then make the pie filling and finally bake the pie—then those could be three more child stories, if we thought we needed to be that precise.

Here is another user story related to our Thanksgiving meal epic: “As a host, I want to send invitations for Thanksgiving dinner, so that my guests know where and when the dinner will be held.” This is an interesting child story because it has nothing to do with cooking or baking, but it is absolutely essential to fulfilling the Thanksgiving epic. You will recall that the user in the epic story is a host. One cannot be a host without having guests, so this child user story gets to the heart of the matter. Now, there will be guests in attendance, so our user is truly acting as a host. Again, this story might split into even more child stories if we wanted to differentiate between writing the invitations, addressing the invitations, mailing the invitations, etc.

As our final example, this could be another child user story: “As a host, I want to set my table, so that my guests have a place to eat dinner.” Again, this user story has nothing to do with cooking or baking, but is essential to hosting a successful dinner party. The guests must have utensils and plates in order to think the host is a good cook, which is the stated goal of the epic user story.

Having the right tools to track parent epic stories and their associated child user stories is quite helpful. Systems are in place that will allow you to enter a story and then write the child stories underneath the parent story; this sort of tracking is particularly useful when you are trying to see how different elements fit together. If you can look up a child story in the system and map it back to its parent epic, it can be very helpful in understanding how the feature works.

“As a host, I want to bake a pie, so that my guests have dessert.” The acceptance criteria might be as follows:

• Verify that the pie is round.

• Verify that the crust is on the outside of the pie.

• Verify that the filling is on the inside of the pie.

• Verify that a toothpick inserted in the middle comes out clean.

This gives the development team much more information about the product owner’s vision of the user story. Again, it should invite conversation. What if the developers know of a new, better way to make pies, but their shape needs to be square? The team can bring this up to the product owner, who might say that the shape is actually quite important and it needs to be round. Or the product owner might say that round is the only shape he or she knew about, so entertaining a new, better option is a great idea. This is the type of collaboration and negotiation that would have been extremely difficult with the Waterfall methodology.

Another example is “As a host, I want to set my table, so that my guests have a place to eat dinner.”

• Verify that each place has a dinner plate in the middle.

• Verify that each place has a dinner and salad fork to the left.

• Verify that each place has a knife and spoon to the right.

• Verify that each place as has a water glass above the knife.

• Verify that each setting has a napkin folded on top of the plate.

Let’s consider another type of negotiation that might take place with this set of acceptance criteria. Perhaps the development team knows that adding a salad fork to the user story is going to add a significant amount of work, maybe even to the point of having to remove other elements from the user story to fit it in. The product owner, the Scrum master, and the team can have an objective conversation about the importance of the salad fork. The product owner might say, based on the market trends and competitive information, that having a salad fork is crucial to launching an effective product to the marketplace, and therefore, it must be included, so perhaps as a trade-off, we can remove the requirement of the napkin. Or the product owner might say that the salad fork was a “nice to have,” not a “need to have,” so we will remove it from the acceptance criteria. Just like everything in Agile, the point is not that you will have blissful interactions with no unanswered questions and no difficult trade-offs; the point of Agile is that we will discuss the trade-offs early and often so we make the best decisions for the product/feature given what we know at the time. Collaboration is the key, and product owners and developers are committed to working together to build the best possible product.

Referring to his recommendations for effective user stories, Roman Pichler says the following about acceptance criteria: “Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done” (Pichler 2010b).

What follows are several discussion points regarding user story writing.

• As a busy executive, I want to be able to save favorites on my mobile weather application so I can choose from a finite drop-down list to easily locate the weather in the destination I am traveling to. In this example, the favorites do not have to be available via a drop-down list, and perhaps one could view that as being too descriptive in the “How.” As long as it is negotiable and sparks collaboration, that additional detail is not problematic.

• As a traveler using the weather application, I want the application to auto-fill based on the first few characters that I type—for example, BOS would bring up Boston as an option—so I can quickly find what I am looking for without typing all of the keys. In this example, the development team might need more around the “What.” How many keys are typed before we offer suggestions? Do we care about capitalization? Do we default to US destinations? However, if we have done something similar elsewhere in the application, then this level of detail could be sufficient.

• EPIC: As a busy executive, I want to be able to save favorites on my mobile weather application so I can choose from a finite drop-down list to easily locate the weather in the destination I am traveling to.

• CHILD 1: As a busy executive, I want to be able to save a search location to my list of favorites from my mobile device so I can reuse that search on future visits.

• CHILD 2: As a busy executive, I want to be able to name my saved searches from my mobile device so I know how to access each saved search in the future.

• CHILD 3: As a busy executive, I want the name of my saved searches to default to the city name, unless I choose to manually override it, so that I can streamline saving my searches.

• CHILD 4: As a busy executive, I want my “saved favorites” option on the user interface to be presented on a mobile device near the “search location” so I have the option of starting a new search or using a saved one, and can minimize my keystrokes within the weather application.

As you can see, breaking down epics can describe a number of elements that might not have been clear in the initial user story. For example, we are going to have to take great care in the user interface to make sure that it is easy to save locations, recall saved locations, and accept/reject the default location name. These aspects may not have been considered with the original epic story and will certainly invite additional conversation about how best to achieve the desired business value.

• Child User Story: As a busy executive, I want the name of my saved searches to default to the city name, unless I choose to manually override it, so that I can streamline saving my searches.

• Acceptance Criteria: Verify that the correct city name is auto-populated when the search found the location by City/State and the Save option is chosen from a mobile device.

• Acceptance Criteria: Verify that the correct city name is auto-populated when the search found the location by the ZIP code and the Save option is chosen from a mobile device.

• Acceptance Criteria: Verify that the default location name is saved to the database.

• Acceptance Criteria: Verify that the default location name is populated as a saved location in future visits.

• Acceptance Criteria: Verify that the location name can be manually overwritten if the default location name is not desired.

• Acceptance Criteria: Verify that the overwritten location name is at least two characters long, alphanumeric.

Again, it is clear from the acceptance criteria that there is a lot to think about for this relatively simple user story. One point that became apparent in the final acceptance criteria is that we have to define the length and parameters for a saved location name. We need to ensure that the definition is acceptable to the database and any downstream systems that may need to save or display that information. Plus, we probably now need a new user story about what error messages will be displayed if the user enters something that does not meet the criteria. For example, if a user just types “A” as the saved location name, we will need an error message that says the location name must be at least two characters; this error handling is an entirely new user story with new acceptance criteria. It represents one of the most valuable things about acceptance criteria—they often create new user stories. This is a great asset because it shows how the team is working together to define more and more of the product up front through thoughtful dialogue, instead of someone just making an uninformed assumption.

In addition, XP also values the importance of user stories for estimation, because the purpose of the stories is to understand the scope of what is requested so we can accurately estimate implementation time (Khramtchenko 2004, p. 6).

• Must have: All features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

• Should have: Features of this priority are important but can be omitted if time or resources constraints appear.

• Could have: These features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

• Want to have: These features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

Alistair Cockburn takes a very user-centric approach to requirements and all aspects of the Crystal Family methodology. In an August 2010 blog, he stated, “We need to learn what the Interests are of the key stakeholders, what the Needs are of the users, and also what the Styles of those key users are. By Styles, I mean the users’ operating styles, the way they might include the product into their life.”

The usability of products and features is core to the Crystal principles, so the requirements should be very mindful of uses and ease of use.

Feature-driven development (FDD) is closely aligned with Scrum because it defines a user story as a feature that is a small, client-valued function that can be implemented in a short period of time (Goyal 2008, p. 8).

As already described, a user story in Scrum follows this format: As a <type of user>, I want <goal> so that <reason>. For example, “As a web site customer, I want the sum of my purchases displayed so that I know how much this is costing me.” FDD uses a convention of: <Action> the <Result> by/for/of/to <object> so the same scenario might read: “Calculate the total of a sale,” where calculate = action, total = result, and sale = object.

Lean software development and the Lean start-up take an innovative approach to requirements gathering and management, so a section later in the chapter is devoted to Lean.

Personas were introduced in software development in 1999 in Alan Cooper’s book, The Inmates Are Running the Asylum. Cooper created these fictitious people to act as users of the system so they could contemplate the user interaction when brainstorming design options.

Some of Cooper’s specific guidance on personas is as follows:

• You want a finite number of personas, so your goal is to narrow down the people you are designing the system for.

• A primary persona is someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona.

• You want to know what the persona’s goals are so that you can see what your system needs to do, and not do.

• If you identify more than three primary personas, your scope is likely too large.

• Sometimes you want to identify negative personas, people that you are not designing for.

Let’s explore a few example personas using our Cayman Design’s weather application. Our grandmother who wants weather alerts could be one persona; we will name her Patricia. She is female, more than 70 years of age, retired, and living in Florida. Patricia has three children and eight grandchildren. Her children live in Charlotte, NC (hurricane and flooding risk), Topeka, KS (tornado risk) and Phoenix, AZ (heat and wildfire risk). She owns a laptop, plays solitaire, and uses e-mail extensively; thus she is slightly ahead of her peers in terms of technology adoption.

A second user persona for our weather application is a busy executive, Sam, who lives in New York City and travels extensively for his job. He is 45 years old, holds an MBA from Harvard, and is currently the CFO at a financial institution. He is married with two children, and he travels about 60% of the time. Sam feels pressed for time and is very adept with technological tools. We will focus our mobile applications and travel status alerts on Sam’s persona.

It is easy to see how developing specific personas can reinforce the needs of the user and allow for a more detailed discussion about the features and priorities that will matter most to them.

Although personas are used by the product owner in the creation of more effective user stories, they can be equally important to the Scrum team because it helps the developers and testers to connect with the end users more intimately and resist the urge to create software targeted at the generic masses (Spagnuolo 2013).

The idea behind HCI and usability is that wireframes or prototypes can be developed “on paper,” or in systems that involve minimal development; the concepts are discussed in more detail in Chapter 9, “Agile beyond IT.” These wireframes are then shown to the product owner and even to the end users so they can react to the workflow and the usability before anything is written in the code; this gives the product owner and the team feedback to improve the stories and the design so the development team starts with something that has already passed a usability screening. Companies that have engaged with an HCI or usability expert are typically pleased with the investment because expensive development resources are not used until the workflows are vetted. There is, however, a note of caution when it comes to incorporating usability designers with Agile because often their work involves months of analysis, so it could restrict the ability of the team to be iterative and collaborative if the entire workflow is preestablished.

Can user experience designers fit within fast-moving Agile teams? Of course. Ideally, we would like the user experience designer to be part of the Scrum or Agile team and to be available to answer questions or clarify items on the features currently being developed. We also want our user experience designers to be one or two sprints ahead of the team, thinking about the upcoming features and how their usability can be considered and tested (Cohn 2010, p. 152).

Another approach that aids in the integration of user experience designers into a Scrum team is to have the developers start on the tasks that are heavy on development and light on user interface work while the user interface designers are investigating, creating, and verifying designs for future sprints (Miller 2005, p. 7).

Like all things in Agile, usability can be incorporated into the flow of the team, provided care is taken to collaborate and learn from the iterations and experiences.

• Increased revenue

• Expansion of addressable market (i.e., with this new feature, more people will be interested in buying it)

• Decreased cost

• Increased customer satisfaction

• Increased processing speed

• Increased stability of the application

• Improved usability

• And more . . .

We should always test our user stories to make sure they are delivering business value, and if they are not, they should be either removed from the backlog or deprioritized to ensure that higher-value features are worked on first.

Here is an example of a user story whose business value is suspect. The Cayman Design team is working on the weather application having the ability to look up locations by city/state, by zip code, and by point of interest; there is a user story in the backlog to add the ability to look up by longitude and latitude coordinates. There is no identified business need for this feature, but it would be really cool to add it, and the developers think it would be relatively easy. The product owner needs to evaluate the business value of this request. Will it increase revenue? No. Will it expand the addressable market? No. Will it decrease costs? No. And so on. Once it is determined that this request/user story will add no business value—despite how cool or easy it is—it should be either removed or deprioritized to let other features that will drive business value be completed first.

This example might be obvious, but it can be harder to discern the low-value user stories when you are trying to define a product. One of the easiest traps to fall into is “the 1% case.” There will always be an instance where one customer might need a feature given a specific set of circumstances, but 99% of the customers/users will never have this need. The prudent product owner is always vigilant about this and makes sure that the team does not work on something for the 1% at the expense of the needs of the 99%. This can be particularly tricky when working with seasoned IT professionals who have had to build for the 1% before, and who can be quite forceful in suggesting that the 1% MUST be considered. It is incumbent then on the product owner to do the research so they have a data-driven response showing how much more important it is to drive business value and to address the needs of the 99%.

• Is this feature complete enough to meet the needs of the marketplace?

• Do we need to release less frequently because releases can be disruptive to our customers?

• How long is our build process? If it takes two weeks to run all of the processes necessary to release code, then you certainly do not want to do it after every sprint.

• Release management, also described in Chapter 4, “Describing the Different Roles,” is an important effort that can differentiate the product in the marketplace and provide the Agile teams with helpful information about how the epics and stories fit into a larger picture. Release management is also a critical element of the Lean efforts that are described later in the chapter.

One way to manage is to decide on a small number of features that will be included in a product launch. At Cayman Design, we accomplished this by coming up with two features that would be included in the first launch—two features and two features only; they were big efforts that would immediately deliver value to current customers and prospects. By knowing the promised features, the marketing team had the information that they needed to prepare collateral materials and product presentations. The sales team was able to start drumming up support in advance of the product launch with absolute confidence of what would be delivered.

Does this give our product owners and Scrum teams enough flexibility to be Agile and to learn as things evolve? Yes, it does.

The secret is that the features are not defined in great detail. The features, as envisioned, would be very rich. As time goes on and new challenges emerge, such as lost resources or unexpectedly complex integrations, the team adjusts the scope by reducing the components that would be included with the committed features. For example, if we started with 100 unique components per feature, we might launch with only 30. This method of managing the product launch can be quite effective: It gives the definition required by marketing and sales while maintaining the flexibility product owners and Scrum teams require to respond to changing variables.

Here are the elements of successfully managing marketing, sales, and customer expectations within Agile:

• Define the features that you are willing to commit to. We suggest no more than three. You want the features to be compelling and broadly defined so you have wiggle room within the scope.

• Unleash sales and marketing to hit the marketplace with the committed features and timeline.

• Between the Scrum team and the product owner, manage expectations and scope for each feature. As complexities or challenges come up, narrow the scope of the committed feature.

• Deliver on time. Once the product is launched, beef up the deployed features with future code releases to add back any removed (actually delayed) scope.

This process will not work for every situation or every product launch, but it can help in many situations.

To summarize how to handle customer-specific (and paid for) code requests, Table 5.1 presents some dos and don’ts.

Although certain aspects of customer-specific code requests do not fit in an Agile framework, there are ways to manage things effectively by being collaborative and transparent with the customer.

Here is a good example of why this is important. Cayman Design is creating a new product that will involve numerous sprints, probably six months’ worth, before the first launch. There is a lot of code to be written and decisions to be made before the product will take its final shape. The team may want to dive right in and start writing code, but taking a moment to share the vision can help with expectations and avoid rework later down the line. For example, reporting is one of the last things that most product launches consider because it comes at the end of the process. Once in the marketplace, the product has to be selected, ordered, delivered, and used before reporting comes into play. However, the decisions that are made about what data to store, in what format, and for how long will dramatically affect Cayman Design’s ability to create reports. Sharing the vision with the reporting team early on can prove to be quite beneficial. The reporting team might notice a key piece of data that they will need to have, and if they can alert the developers before the code is written, it is much easier than trying to add a new data element after the code has already been designed, written, and tested.

Sharing the vision also forces the product owner to have a vision. This may sound like an obvious statement, but sometimes people are moving so fast, from project to project, from action item to action item, that they do not stop to take a breath and review the big picture. Stephen Covey captures the essence of this concept when he compares managers to leaders:

You can quickly grasp the important difference between leadership and management if you envision a group of producers cutting their way through the jungle with machetes. They’re the producers, the problem solvers. . . . The leader is the one who climbs the tallest tree, surveys the entire situation, and yells, “Wrong jungle!”

As individuals, groups, and businesses, we’re often so busy cutting through the undergrowth we don’t even realize we’re in the wrong jungle. (Covey 1989, p. 101)

In Agile, we want our product owners to demonstrate true leadership over their product, to know if the Scrum team is coding in the right jungle. By having a presentation or meeting about the desired deliverable, the product owner has the opportunity to stop and think about what he or she is trying to achieve; articulating this vision might help the product owner find gaps or potential problems in his or her thought process. And by sharing it with others, the product owner benefits from the wisdom of the group, who will ask provocative questions and drive further clarifications.

Some Agile purists have a hard time with the concept of roadmaps because Agile is supposed to be iterative and constantly changing to respond to the needs of the marketplace. Although this is true, most companies and their customers expect a degree of transparency and commitment about what is to come. Cayman Design is a company selling directly to consumers (business to consumer, or B-to-C), so a published roadmap may be less important than for a company serving other businesses (business to business, or B-to-B). Because B-to-B customers might be building their own software to interconnect, they need to be able to anticipate the features and dates so they can align their own roadmap with the company’s deliverables. Figure 5.2 presents an example of an external roadmap.

Both internal and external roadmaps require a clear owner of who is responsible for information updates, the frequency of updates, and communication strategy. Typically product owners or product managers own the roadmaps and update them weekly, monthly, quarterly, or as needed, depending on the nature of the core business. Communication can vary from e-mail notification of an update, to a formal meeting, to simply making the updated information available on a shared collaboration site. Roadmaps are not a requirement for Agile, and as mentioned, some purists do not like them, but they are typically part of the reality for an organization, so determining what to include and how to produce roadmaps is a worthwhile discussion.

Many aspects of Lean can be applied outside of manufacturing. Two brilliant Agile minds, Mary and Tom Poppendieck, were the first to adapt the principles in their book, Lean Software Development: An Agile Toolkit (2003). Their approach was targeted at the software development cycle, and they came up with seven core principles that compose their toolkit (Poppendieck and Poppendieck 2003, p. xvi):

1. Eliminate waste. Waste is anything that does not add value to a product, value as perceived by the customer.

2. Amplify learning. Development is an exercise in discovery.

3. Decide as late as possible. Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation.

4. Deliver as fast as possible. Design, implement, feedback, improve: The shorter these cycles are, the more can be learned. Speed assures that customers get what they need now, not what they needed yesterday.

5. Empower the team. Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work.

6. Build integrity in. Software with integrity has a coherent architecture, scores high on usability and fitness for purpose, and is maintainable, adaptable, and extensible.

7. See the whole. The interdependencies between systems and processes must be optimized as a whole, or else the customer experience becomes fragmented and suboptimized.

A slightly different adaptation of the “Lean” movement came from Eric Ries with his groundbreaking book, The Lean Startup, which has created an entire movement, not unlike Agile. Ries explains why some start-ups or entrepreneurs fail while a small percentage actually succeed. One explanation is that markets are changing so quickly that product development cycles, even when using Agile, are having a hard time keeping up. Ries suggests that product owners define the minimum viable product, or MVP, with the minimum features required to address a need in the marketplace; they launch with that very thin product offering, see how the market responds, and then course-correct in future launches. It is a radically different way to look at product development because the goal is not to launch a fully functional product; it is to be quick to market with something that solves a piece of the business problem and expand from there. The reason why Lean product development is getting so much attention and traction is that many companies have spent years developing something that the market either does not want or will not pay for; this gets the product in front of the paying public with the minimum effort possible. Based on how the product is received and what features deliver the most value (and hence the highest ROI, return on investment), the product owner and development team can quickly reprioritize the backlog to respond to real market feedback to continue to add business value and drive revenue.

The value of Lean is incorporating a continuous feedback loop from actual customers, which is more reliable and honest than internal feedback, so the teams can continuously learn and work on the most important things with a minimal amount of waste. It is easy to see how these engineering and manufacturing principles make so much sense in the world of software development. It is absolutely critical that the product owner envision a product that is needed in the marketplace. After all, Peter Drucker has been quoted as saying, “There is surely nothing quite so useless as doing with great efficiency what should not be done at all” (Goodreads 2013).

To illustrate the idea of the minimum viable product, let’s look at Cayman Design and our weather application. We made the decision, as detailed in Chapter 4, that we would launch our weather application with only data for New York City. Some might consider this a risky move since we have a limited target audience; we could have waited until data for Boston, Dallas, and San Francisco was included as well and would likely have had more traffic and certainly more users. By choosing the MVP with only New York City data, we were able to get our product out in the marketplace sooner, and we could immediately start gathering real feedback from real users. By investigating the site analytics, we can learn where our New York users are spending most of their time and where they are getting hung up in the application; using Agile, we can then quickly incorporate that feedback into subsequent releases of the software. Thus, when we expand to Boston and other cities, we are doing so with actual user-driven improvements.

Product owners and others responsible for gathering customer feedback will see the value of Lean software development and the minimum viable product, but they may need to fight the internal organizational inertia to build a robust, feature-rich product. The concept of starting small and gathering input to influence future deliverables is usually understood and supported; the actual activity of releasing something to the marketplace that is limited in its features and addressable audience is often harder to embrace.

• In Agile, a user story, by definition, must be small enough to be designed, coded, and tested in single sprint, or iteration.

• The user story format is As a <type of user>, I want <some goal>, so that <some reason>. Each element is important for helping to clarify exactly what we are trying to accomplish with our software.

• We want to INVEST in good user stories, meaning that they are Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

• Epics are user stories that are too large to be completed in a single sprint. Most user stories start as epics, and there is no need to break them down into smaller user stories until the team is getting close to working on them.

• Acceptance criteria are the details added to a story representing how a story will be “graded” or deemed complete by the users. Acceptance criteria often lead to healthy conversations about trade-offs between development teams and product people.

• DSDM employs a prioritization method called MoSCoW, where stories are depicted as Must Haves, Should Haves, Could Haves, and Wants.

• The Crystal Family methodologies focus heavily on the user experience and understanding exactly how end users will interact with the software.

• Feature-driven development has a similar user story format to Scrum: <Action> the <Result> by/for/of/to <object>.

• A persona is a fictitious character that represents a key user of the system. Personas are named and detailed to assist in the requirements clarification and prioritization process.

• User experience designers and HCI experts contribute to strong requirements by mapping and testing the workflows and usability considerations before development begins.

• Release management is the activity of grouping features and enhancements together into a compelling release to the marketplace.

• Customer-specific code is a challenge in Agile development practices, but it can be incorporated with a few clear interactions.

• All product development efforts should be guided by a vision for the product that is clearly articulated and understood throughout the organization.

• Roadmaps (both internal and external) are communication devices that bring transparency to Agile development efforts.

• Lean software development and the minimum viable product (MVP) of Lean product development are great adaptations of Agile principles in a competitive marketplace where real user feedback is essential.

Mary Gorman, vice president of Quality and Delivery with EBG Consulting and coauthor of Discover to Deliver with Ellen Gottesdiener, is an expert business analyst, facilitator, coach, and trainer. She has deep expertise in business systems, product development, and Agile analysis. Mary has been a driving force for Agile within the International Institute for Business Analysis (IIBA) by spearheading the IIBA^® Business Analysis Body of Knowledge^® and the IIBA^® certification exam. She is a CBAP™ (Certified Business Analysis Professional™) and Certified Scrum Master. Mary’s experience allows her to work with global clients, speak at industry conferences, and continue to write on requirements topics for the Agile and business analysis community.

Kristin and Sondra: What is different about Agile requirements?

Ellen and Mary: With Agile, it’s a different mind-set. You don’t think of requirements as a static set of statements to be implemented. Rather, you expect and enable your product to evolve in functionality and value as you continually discover and deliver high-value product options.

During planning, you think of requirements as not-yet-validated options for achieving a certain value by solving a problem or taking advantage of an opportunity. After delivery, you validate whether or not the built option provided the anticipated value. In Agile, the goal is to assess value constantly, adapt as conditions change, and deliver value quickly and often.

Kristin and Sondra: How do you measure business value as it relates to story prioritization?

Ellen and Mary: The product’s business value—what the sponsoring party will gain or possibly lose—is both tangible and intangible. Tangible value comes from meeting business goals and objectives and is often measured in revenues and costs. The product’s intangible value may be more difficult to identify and measure. It might include the product’s desirability or how the product affects the company’s reputation.

Your product—whether it’s an application, a service, or a system, and whether it’s commercial or internal software—must deliver both tangible and intangible value to be successful. When prioritizing stories for the next planning horizon, you elevate those that will deliver value.

Kristin and Sondra: How do Agile teams gather requirements?

Ellen and Mary: We prefer to use the word “elicit” rather than “collect” or “gather.” “Elicit” connotes that we draw out, deduct, derive, infer, provoke, and evoke requirements during discovery. This is important and challenging work! Elicitation goes hand in glove with analysis. As we elicit, we analyze, which may lead to further elicitation for clarity and elaboration of requirements.

Another distinction is our definition of “team.” The team needs to include stakeholders from three realms: business, technology, and customer. They work together as product partners to envision and deliver the product.

Elicitation and analysis work best when teams use techniques that engage, involve, interest, challenge, and excite the product partners as they conduct what we call “structured conversations” to explore, evaluate, and confirm product options. Such conversations are structured around a framework we call the 7 Product Dimensions. These are the seven categories of product options: requirements regarding the users, the interfaces, the actions, the data, the controls (constraints), the environment, and the quality attributes of the product.

Note that the 7 Product Dimensions include nonfunctional as well as functional options. Collectively, they provide a holistic view of the product.

As they work, team members keep in mind that requirements come in varying levels of granularity, depending on the planning horizon you’re working in—that is, the time period you want your plans to cover. We divide the planning horizons into three: the Big-View (as long as two years), the Pre-View (the next product release, typically a few months), and the Now-View (the next iteration, typically a few weeks). You can think of these levels as Wants (Big-View), Needs (Pre-View), and Requirements (Now-View). In this scheme, the requirements are small, carefully sliced, and highly granular.

Kristin and Sondra: What are the most important aspects of a good user story?

Ellen and Mary: We’ve found stories to be useful conversation starters. We use the structured conversation to explore and evaluate a story across the 7 Product Dimensions. For example, the partners learn who the user is, which interfaces are needed, what the detailed actions are, which data is created, read, updated, and/or deleted, which controls must be enforced, what the user’s environment is like (where they will actually interact with the product), and what quality attributes are needed (availability, performance, security, etc.). The conversation isn’t complete until the story is “confirmed.” The partners define concrete examples and unambiguous acceptance criteria to ensure that their expectations of the story are the same.

To recap, a user story needs to address all 7 Product Dimensions. The structured conversation is a framework for exploring, evaluating, and confirming the partners’ understanding of the story.

Kristin and Sondra: What are the best tips for managing scope creep?

Ellen and Mary: Here are our top five tips:

• Develop a vision for the product, and define the goals and objectives you anticipate the product will deliver.

• Identify and collaborate with the stakeholders (customer, business, and technology partners) early and often throughout discovery and delivery.

• Ground your scope decisions in the product’s vision, goals, and objectives, as well as the partners’ value considerations.

• Use lightweight, organic models to analyze all 7 Product Dimensions.

• Get real! Use concrete examples to explore and confirm the product.

Kristin and Sondra: What is the most important coaching advice that you give to teams?

Ellen and Mary: Be transparent—identify and socialize the product’s ends (vision, goals, objectives) along with the partners’ value considerations. Be collaborative and creative—use a variety of techniques to engage the partners and visualize the product’s requirements. Be open, clear, and consistent when making product decisions.

Ambler, Scott. Personas. http://www.agilemodeling.com/artifacts/personas.htm.

Coad, Peter, De Luca, Jeff, and Lefebvre, Eric. (1999). Java modeling in color with UML: Enterprise components and process. Upper Saddle River, NJ: Prentice Hall.

Cobb, Charles G. (2013). Managed Agile development: Making Agile work for your business. Parker, CO: Outskirts Press.

Cockburn, Alistair. (2006). Agile software development: The cooperative game (2nd ed.). Boston: Addison-Wesley.

Cockburn, Alistair. (2010). Requirements are sins. Blog entry, August 20. http://alistair.cockburn.us/Requirements+are+SINs.

Cohn, Mike. (2004). User stories applied: For Agile software development. Boston: Addison-Wesley. Kindle edition.

Cohn, Mike. (2008). User stories for your product backlog. http://www.mountaingoatsoftware.com/uploads/presentations/User-Stories-Product-Backlog-Scrum-Gathering-Chicago-2008.pdf.

Cohn, Mike. (2010). Succeeding with Agile: Software development using Scrum. Boston: Addison-Wesley.

Cooper, Alan. (1999). The inmates are running the asylum: Why high-tech products drive us crazy and how to restore the sanity. Indianapolis, IN: Sams Publishing.

Covey, Stephen R. (1989). The 7 habits of highly effective people. New York: Free Press Simon and Schuster.

DSDM. (2011). Dynamic Systems Development Method. http://dsdmofagilemethodology.wikidot.com.

Goodreads. (2013). http://www.goodreads.com/author/quotes/12008.

Gottesdiener, Ellen, and Gorman, Mary. (2012). Discover to deliver: Agile product planning and analysis. Sudbury, MA: EBG Consulting.

Goyal, Sadhna. (2008). Major seminar on feature driven development Agile techniques for project management and software engineering WS 2007/08. Munich: Technical University of Munich. http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf.

Goyal, Sadhna. (2010). Influence of bugs on a software project: Effect of time of bug discovery on the duration and budget of a software project. Saarbrücken, Germany: VDM Verlag Dr. Müller.

Grosjean, Jean Claude. (2009). Personas in Agile development: YES we can! Blog entry, December 2. http://www.agile-ux.com/2009/12/02/personas-in-agile-development-yes-we-can.

Khramtchenko, Serguei. (2004). Comparing eXtreme Programming and feature driven development in academic and regulated environments. Final paper for CSCIE-275: Software Architecture and Engineering, Harvard University, May 17. http://www.featuredrivendevelopment.com/files/FDD_vs_XP.pdf.

Marchesi, Michele, Succi, Giancarlo, Wells, Don, Williams, Laurie, and Wells, James Donovan. (2002). Extreme Programming perspectives. Upper Saddle River, NJ: Pearson Education.

Miller, Lynn. (2005). Case study of customer input for a successful product. Alias, Proceedings of Agile conference, Toronto, Canada. http://agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf.

Pichler, Roman. (2010a). Agile product management with Scrum: Creating products that customers love. Boston: Addison-Wesley.

Pichler, Roman. (2010b). 10 tips for writing good user stories. Blog entry, October 7. http://www.romanpichler.com/blog/user-stories/writing-good-user-stories.

Pichler, Roman. (2012). A template for writing great personas. Blog entry, May 3. http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-management.

Poppendieck, Mary, and Poppendieck, Tom. (2003). Lean software development: An Agile toolkit. Boston: Addison-Wesley.

Ries, Eric. (2011). The Lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown.

Spagnuolo, Chris. (2013). Know your users—create personas. Blog entry, January 8. http://agile.dzone.com/articles/know-your-users-create.

Wake, Bill. (2003). INVEST in good stories, and SMART tasks. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks.

Wells, Don. (1999). User stories. http://www.extremeprogramming.org/rules/userstories.html.

Wells, Don, and Williams, Laurie. (2002). Extreme Programming and Agile methods—XP/Agile. Universe 2002: Second XP Universe and First Agile Universe Conference, Chicago, August 4–7 (Lecture Notes in Computer Science). Berlin: Springer.

2. Name three of the six elements of a user story represented in the acronym INVEST.

3. What is an epic?

4. What are the MoSCoW rules in DSDM?

5. What is Crystal software development very interested in with regard to requirements?

7. Can user experience designers participate on a Scrum team? Why or why not?

8. What are three examples of business value?

9. What is release management?

10. For customer-specific code, how should the team incorporate customer feedback and potential changes to the scope of the project?

12. Are external roadmaps typically accessible by the public (everyone)? Why or why not?

13. What are the differences in terms of audience, details, and committed dates between internal roadmaps and external roadmaps?

14. Who owns the roadmap creation, updates, and communication?

15. How does the transparency afforded by Agile help the organization?

17. Why does the Lean software development advocate for making decisions as late as possible?

18. What could real user feedback tell you about your product that internal conversations would not reveal?

19. Should user stories be complete and thorough before discussions begin with the development teams? Why or why not?

20. Why is the Agile way of gathering requirements such an improvement over the Waterfall methodology?