Sprinting to the finish

Under scrum, development occurs in short, defined periods called sprints, which are up to two and no longer than four weeks long. The goal of each sprint is to create code in an iterative and incremental way and complete a particular piece of work. This process is repeated (iterated) while the product is progressively built (increments).

For each sprint, the development team takes work from the top of the product backlog (discussed in detail later in this chapter) focusing on the top priority items that can be developed during the allotted time. The team breaks down the work for each sprint into tasks and then executes each task. Quality assurance occurs in parallel (simultaneously). If a task won’t be completed in its given sprint, it’s pushed out to the next sprint.

However, each sprint can be released to customers as soon as it is complete. Alternatively, several sprints are often bundled together and provided to customers in a larger product release. Figure 12-3 shows the cascading relationship between tasks in a sprint, sprints, and a product release.

Telling (user) stories

In Agile, you communicate the requirements through simple user stories to the engineers instead of writing and signing off on a comprehensive MRD as in waterfall. User stories can be simply written on a 3-x-5-inch notecard, or they can be captured electronically in a database or Agile development software system. The focus is on communicating and working as a team while minimizing documentation. The user stories convey to the engineer what the customer need is and what the user is trying to accomplish. Once the engineer has discussed the user story with the product manager or product owner and fully understands the meaning of the user story, the engineer then builds the feature.

The format of a user story is as follows:

As a <persona>, I want to be able to <customer need> so that I can <benefit of requirement>.

Figure 12-4 is an example of a user story.

Story mapping

Story mapping is a technique, developed by Jeff Patton, of mapping out the particular activities that need to happen in the product to make sure a customer accomplishes her goal. The wonderful thing about a story map is the clarity it gives you and your development team about what completely addressing a customer need will take. In the best case, you bring everyone together in one room and work the story from beginning to end. The process generates significant learning and understanding on all sides, which leads to less confusion for the duration of the project.

To create a story map, you can use sticky notes, markers, dots, colored masking tape, and a blank wall space. In Figure 12-5, you can see how you start by creating a backbone of user activities at the top. These can be logging into the software, selecting a product, and going through the check-out process. Under each of these activities are tasks (not necessarily the same as the tasks which drive development work within a sprint). Under each task, the development team fills in all the subtasks, user interface, and other details that the user needs to complete the tasks. Once all the development tasks have been documented, the list of tasks is divided into what absolutely must be done to bring the product to market. This first slice is your minimum viable product. The work done in future releases is allocated to the next slice.

Prioritizing the backlog

As we know, in Agile, the basis for a development team to create a working piece of software is a user story. It’s the smallest block of development. The next size up is a feature. And even larger is an epic. (In Europe, the term for an epic is a saga.) So remember: user story < feature < epic.

Here’s an example of an epic, feature and user story for an online store selling shoes. The epic has a larger scope of work than the feature which is again, more work than the user story. The user story is the smallest slice of work that the product manager typically works with.

• Epic: As a customer, I want to be able to purchase shoes online so that I easily compare a wide range of shoes from the comfort of home.
• Feature: As a customer, I want to be able to purchase the shoes I have selected so that I don’t have to look around a lot of shops.
• User story 1: As a customer, I want to be able to pay by a range of most commonly used credit card options so that I can choose a convenient payment option.
• User story 2: As a customer, I want to be able to input the city where the shoes will be delivered so that I can receive my shoes.

User stories 1 and 2 both address parts of the feature, but not all of it. And the feature addresses some of the epic but again needs other features to complete all aspects of the epic.

As you can see in Figure 12-6, your product backlog consists of many of these user stories, features, and epics. As you investigate proposed development work, you realize that some work has more customer value than others. This work should then be done earlier. The reality of development is you simply can’t get to the level of detail needed for the entire product upfront. You would spend a huge amount of time upfront in development breaking down each and every piece of work to be done while developers twiddled their thumbs. Instead, you prioritize the proposed work by customer value and create a prioritized product backlog, most often referred to as a prioritized backlog or more simply backlog.

At the top of the backlog, you have your user stories that the development team are just about to start with; below that are your features and then your epics. As features and epics come to the top of your backlog, you break them down into user stories that your development team can work on.

So what do you work on first? A lot depends on what you’re building. If you’re just starting out, building out a software structure or architecture for what comes later is usually most important. For an ongoing product, the items at the top of the backlog are most definitely what has the most value both to the customer and your company. The reality is that sometimes you have to prioritize a bug fix or solve a larger structural issue with the software, which is referred to as technical debt.

The beauty of a product backlog is that one person is in charge: the product owner (or product manager in the role of product owner). That is an absolute within scrum. This person decides what the development team works on next. That said, it would be a poor product owner who didn’t get feedback to make sure that the development team lets her know what would make most sense to complete next.

Documenting the product backlog

The issue with tracking an Agile backlog is that the volume of information is huge. Most teams move quickly away from documenting each piece of information with index cards and switch to software written for this purpose. A side benefit of using software tools is that tracking is integrated so it’s also easier for you to figure out what stage each piece of work is at. When you know what software your development team is using, spend the time to learn all the ins and outs so that you can use it to efficiently document the product backlog.

Invest in features

When you write down your product features, a good rule of thumb to see if you’re headed in the right direction is to use the acronym INVEST (kudos to Bill Wake for this idea). Table 12-1 tells you all the aspects of a good product feature or user story. The “small” rule is critical to Agile only. The rest are applicable to both waterfall and Agile requirements.

When is a feature really a constraint?

In creating a product, you sometimes have features or user stories that are really hard to write. They don’t seem to fit into the usual user story pattern. These are better written as constraints. For example, how long should a task take? What operating system(s) should it operate under, or what temperature range should it operate within? Simply write down the limits of what the product needs to do without reference to a customer and move on.

Examining Agile’s manifesto and key principles

Agile in all of its different forms was created based on the principles stated in the Agile Manifesto, shown in Figure 12-7. The Agile Manifesto was created by a group of software developers who were looking for a more optimized way to develop products and bring features to market faster. Over time Agile has started to be applied to many types of products beyond just software.

Agile has 12 key principles shown in Figure 12-8.