Starting with user stories, epics, and themes

As I explain in Chapter 1, a user story is a description of a product feature from the user’s perspective; for example, “As a mobile phone user, I need to know whether the cell signal is strong enough so that I’m sure to have a clear conversation when I place the call.” The most common format for user stories is this:

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

The last part of the user story is actually the most important, because it describes the pain point the product needs to address and indicates the value that the feature must deliver to the customer. In the example of the mobile phone user, what’s most important to the user is that the cell signal is strong enough to support a clear conversation. The user story is general enough to give the developers room to come up with various ways to deliver this value to the user. For example, the developers may decide to display bars or dots on the screen to indicate signal strength, they may tweak the software to improve the audio compression, or they may even develop a better way for the phone to lock in a signal.

The purpose of a user story is to spark a conversation about how to meet that need and deliver value to the customer. Prior to user stories, developers were given well-defined software requirements that ended conversations and stifled innovation. Management told the developers what to do and how to do it. With user stories, customers tell developers what they want, and the developers determine how to deliver it. The developers may deliver what the customer wants in ways that the customer and management never would have imagined.

In addition, user stories get customers more involved in the product development process, because they enable customers to describe what they want without having to know anything about the technology.

Don’t confuse a user story with a use case, which is a much more detailed description of how the user interacts with the software and how the software behaves and interacts with other systems. While user stories are often one or two sentences written on an index card, a use case is typically a page or more of functional requirements. Perhaps more important, user stories are intended to start conversations, whereas use cases tend to shut them down.

A couple terms related to user stories are epics and themes:

• Epic: A big user story; for example, “As the owner of an appliance repair shop, I need to automate my inventory system so that I always have the parts available to complete a repair.”
• Theme: A collection of related user stories, such as all user stories related to inventory management or all user stories related to producing monthly reports.

Estimating with story points

Instead of following a detailed plan and schedule to deliver product, agile teams work to continually create product iterations that gradually integrate more and more value into the product. For example, a team may start with a list of user stories, prioritize that list, and then work in two- to three-week time blocks to complete each story. Instead of a detailed plan, agile teams work off of something that looks more like a to-do list. Instead of using milestones or deadlines that are often subject to change (because nobody knows exactly how long certain work items will take to complete), agile teams use various collaborative estimation techniques to give ballpark estimates that reflect the relative sizes of work items, such as the following:

• Animal sizing: I often recommend agile teams go to a toy store and purchase a deck of cards with animal pictures on them, such as horses and ducks, so that they focus less on trying to score jobs and more on using the cards to open up a discussion of what each job entails. Animal sizing is similar to using a Fibonacci sequence; using animal pictures instead prevents the team from focusing on numbers. Some teams are tempted use Fibonacci numbers as days or hours. The animals keep your team focused on sizing.
• Big, uncertain, and small: For super-fast estimation, consider using three categories of work — big jobs, small jobs, and uncertain jobs that are tough to estimate because they may have uncertainties that can result in delays.
• Fibonacci sequence: A Fibonacci sequence is a series of numbers in which each number is the sum of the preceding two numbers (for example, 1, 2, 3, 5, 8, 13, and 21). These numbers represent level of effort, not hours or days. A two is roughly twice as difficult as a one. And eight is roughly four times as difficult as a two.
• T-shirt sizing: Agile teams may use T-shirt sizes, such as XS (extra-small), S (small), M (medium), L (large), XL (extra-large), and XXL (extra-extra-large).

However you choose to rank items, keep in mind that ranking reflects more than just the estimated amount of time required to complete a job. Rankings should consider the amount of work, complexity of work, coordination of any external dependencies, the risk or uncertainty involved (which may result in delays), and the time/duration.

Agile teams use a variety of estimation techniques, including the following:

• Affinity mapping: The team groups items that are similar in whatever dimension they choose, such as degree of difficulty, duration, or uncertainty. After grouping the items, the team can then assign a number or other size designation to each group.
• Bucket system: The team creates a number of “buckets” to represent difficulty levels. Then the team assigns relative estimates to these buckets. You could use 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50. Someone selects a work item randomly from the stack of work items that need to be completed, reads it to the group, and sticks it in the middle bucket. In this case, the bucket with the number 5. The team estimates the remaining items relative to the middle bucket while discussing the placement with other team members. The team then does a “sanity check,” where team members can discuss any disagreements they have over placements and reach consensus on the placement of all items. The bucket system is fast, and it’s a great technique to use when you have a considerable number of work items.

• Planning poker: Everyone on the team has a stack of playing cards with numbers on them that indicate the relative difficulty of a work item. Each person chooses a card, and then everyone flips his card over when the facilitator gives the signal. If all “scores” match, that becomes the estimate for the work item. If the cards have different scores, team members explain the reasons for their scores, and voting repeats until the team reaches consensus or has bid three rounds without converging (in which case the work item is set aside for further refinement). The most important factor is the rapid learning (from each other) that takes place during these discussions.

  Most agile teams use a deck with a modified Fibonacci sequence. This typically has a number sequence, such as 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. (The sequence is close to being exponential in order to reduce disagreement; getting a group to decide between a 5 and an 8 is easier than getting them to agree between 7 and 8.) Each person usually has a card with a question mark and another with a coffee cup that are to be used sparingly to indicate uncertainty or to ask for a break.

Whatever technique you use, approach it more as a group discussion technique. Don’t push for consensus on a number at the expense of having a good discussion. And don’t promote an average of the scores. Teams create bad estimates when they don’t have a shared understanding of what it takes to deliver the story. It’s that shared understanding that’s the most important part of any estimation technique.

The purpose of planning poker and other agile estimation techniques is to limit any bias that may influence the estimates. Group decision-making often suffers from the following sources of bias:

• Anchoring: The group supports the first opinion expressed by someone in the group who has a strong personality. That first opinion serves as an anchor that makes it difficult for anyone else to change direction, because in order to do so, members must first prove that the opinion expressed is wrong.
• Dunning-Kruger effect: The loudest person in the group — who’s usually wrong — drives the group’s decision. David Dunning and Justin Kruger, two social scientists, found that the people who are wrong typically have the strongest opinions and are most vocal in expressing them. The people who are quieter and less confident are more likely to be correct.
• Groupthink: To avoid the messiness of confrontation, people refrain from expressing their honest opinion, because they think it will lead to conflict.

Estimation techniques, including planning poker and the bucket system, require that all members give an opinion without knowing what their other team members think. Team members with strong opinions or those who are more vocal than the others can still drive the team in a certain direction, but at least the discussion begins with less biased views.

Queuing up work

Every agile framework employs queueing theory to manage workflow. (Queueing theory is the mathematical study of how items move through a sequential system.) The idea is to reduce bottlenecks that often result when you try to push large batches of items through production. To improve workflow and reduce cycle times (the time to complete work items), agile teams try to create batches of work that are uniform in size and can be completed over the course of a single production cycle (which is why they employ estimation techniques, such as those described in the previous section).

Although different agile frameworks approach queuing in different ways, they typically start with a product backlog (a prioritized list of items that must be completed to deliver the product). They draw items from the top of the product backlog to create a list of items that the team is reasonably sure it can complete within the given time frame, and then the team uses a system, such as a Kanban board, to track work in progress. As I explain in Chapter 1, a Kanban board has several columns that represent stages in the development process, such as “To Do,” “In Progress,” and “Done.” A description of each item is written on a sticky note or index card and placed in the first column, and then as the team works on and completes the item, it moves the note or card to the next column. (For more about Kanban, see Chapter 8.)

Conducting stand-up meetings

To reduce the time wasted in unproductive meetings, agile teams usually conduct daily 15-minute meetings in which all team members stand around in a circle to sync up with each other and coordinate their game plan for the next 24 hours. They stand to reinforce the notion that these meetings must remain brief and crisp, just enough to make sure everyone is “on the same page” together. Traditionally, team members may use a round-robin approach and take turns addressing questions. (See “Standing up for the Daily Scrum” later in this chapter for more details.)

The daily stand-up meeting is typically conducted in the morning to help transition into the day’s work and to avoid interrupting work later in the day. However, it is up to each self-organizing development team to optimize its daily routine by choosing the time slot that works best for it.

Shifting to test-driven development

Agile teams often take a test-driven development (TDD) approach to creating new software — writing a test case, designed to fail, that defines an improvement or new function and then writing just enough code to enable the software to pass the tests. The team then refactors the code to clarify and simplify the design. TDD encourages developers to think about what the software will accomplish before they begin coding. It also encourages writing lots of tests to improve the quality of the software. A typical test-driven developer will add a test, run the test, write the code, rerun the test, refactor the code, and repeat if necessary.

TDD enables teams to focus solely on developing a product that passes a specific test rather than on the product as a whole, thus increasing productivity and delivering cleaner code that’s less buggy. TDD also supports the practice of continuous integration, discussed next.

Developing product iterations through continuous integration

Continuous integration (CI) is the practice of merging code changes into a share repository several times each day to achieve the following two objectives:

• Minimize the duration and effort required to integrate new code into existing software.
• Develop a version of a product (a product iteration) that’s suitable for release at any time during the development process.

To understand the concepts of continuous integration and product iterations, compare traditional product development with agile development as they may be applied to building a car. With a traditional approach, developers might start with a wheel and then create a chassis, add a body, and then add seats, a steering wheel, and an engine, as shown in the top of Figure 2-1. In contrast, an agile team may start with a user story that is something like, “As an employee, I need a vehicle, so that I can get to work faster.” The team would then set out to create various iterations of a vehicle that would get the employee to work faster than if the employee had to walk, as shown in the bottom of Figure 2-1. The first vehicle may be a skateboard, the next is a scooter, and then a bicycle, a motorcycle, and finally a car. Each iteration would be a fully functioning vehicle.

This iterative approach offers many advantages, including the following:

• Every iteration results in a potentially deliverable product.
• The team has many opportunities to inspect and adapt the product over the course of development. Team members could even decide at some point to create a flying vehicle to help the employee avoid traffic.
• The team learns along the way and develops knowledge and skills to improve the quality and value of the product. In this example, by the time the team is working on the motorcycle, it has probably learned a great deal about wheels, structural design, and transportation.
• The customer has the opportunity to opt out at any time; for example, if the customer falls in love with the motorcycle, he may decide that the expense to engineer a car isn’t worth it.

Transitioning from a traditional approach to product iterations is often challenging, because it requires transforming the company from one that’s organized around functional areas to a team-based, cross-functional model. For example, in a typical organization, marketing may have an idea for a product; developers build the product, and then quality assurance tests it. Many companies have trouble imagining an approach for delivering a smaller version of a completed product with marketing, design, development, and quality assurance all baked in at the team level.

Wrapping your brain around Scrum theory

Scrum is an empirical process framework, as opposed to a model framework. “Empirical” means data-driven — gaining knowledge from direct observation and experience and basing decisions on what is known. Instead of engaging in a lot of up-front planning that’s often based on conjecture, Scrum teams experiment, inspect, and adapt, relying on empirical data to drive their decisions.

As an empirical process framework, Scrum is built on the three pillars of transparency, inspection, and adaptation, as explained next.

Getting up to speed on Scrum values

Scrum stipulates five values every Scrum team should embrace:

• Commitment: Every team member must be personally committed to achieving the team’s goals.
• Courage: Team members must have the courage to do the right thing and tackle difficult problems.
• Focus: Everyone on the team must focus on the work and on achieving the sprint goal.
• Openness: All team members and other stakeholders agree to be open about their work, mistakes, limitations, expectations, and obstacles. Think of openness as transparency at the team level.
• Respect: Scrum team members respect and trust one another as capable members of a community.

Working in a Scrum team

Every Scrum team has a product owner, a Scrum Master, and a development team, and every team is self-organizing and cross-functional:

• Self-organizing: Instead of being managed by someone outside the team, the team members decide the best way to accomplish their work.
• Cross-functional: The members of each team have all the knowledge and skills to accomplish their work without having to rely on others.

Stepping through Scrum events

Scrum has five events that provide some regularity throughout the product development process while minimizing time spent in meetings:

• Sprint planning: A two-part meeting devoted to what must get done during the sprint (the first part) and how to get it done (the second part).
• Sprint: A two- to four-week time frame in which the development team completes its list of work items.
• Daily Scrum: Brief daily team meetings to report progress and discuss impediments.
• Sprint review: A post-sprint meeting to discuss the current state of the product and what needs to be done in future sprints.
• Sprint retrospective: A post-sprint meeting in which the team discusses ways to improve the way the team functions.

All events are time-boxed, meaning each event has a maximum duration. For example, the Daily Scrum has a maximum duration of 15 minutes.

I describe these events in greater detail in the following sections.

Prioritization is one of the keys to successful use of time boxes. The team focuses on the most important items first. That way, if the team should run out of time, it can be confident that it made the best use of the time box.

Producing Scrum artifacts

Scrum specifies that teams produce the following four artifacts to provide transparency and to support inspection and adaptation:

• Product backlog: A prioritized list of work items to be completed to create the product.
• Sprint backlog: A prioritized list of work items to be completed over the course of a single sprint to deliver a potentially shippable product increment.
• Product increment: A fully functioning rendition of the product.
• Definition of “done”: A set of requirements that indicate when a product increment is considered finished.

In the following sections, I describe each of these artifacts in greater detail.

Growing Scrum

Because of Scrum’s popularity, Scrum teams are included in nearly all enterprise agile frameworks, which puts the developers of enterprise agile frameworks in a bind. On the one hand, they celebrate the simplicity of Scrum, which is what made it appealing to so many organizations. On the other hand, they must argue that Scrum is not enough so that they can justify the need for a larger framework.

When you see Scrum included in an enterprise agile framework, ask yourself whether it’s really Scrum. Some enterprise agile framers create their own version of Scrum, while others scale up Scrum by adding extra roles and processes. Still others create a new network of different practices as a way to connect several Scrum teams.

Each of these approaches adds a lot of external baggage to a simple framework. Remember that the three pillars of the Scrum framework are inspection, adaptation, and transparency, which means that any good Scrum team must use any expanded practices as a way to inspect and adapt. You don’t want to add anything that weakens the three pillars. You don’t want to grow Scrum to the point where you’re losing the advantages of working as a small, self-directed Scrum team.

Checking out XP’s values

Like most agile frameworks, XP is driven by a set of values that its practitioners embrace to work in harmony with one another and in alignment with personal and corporate values. Its creators suggest starting with the following five values and adding values to reflect your organization’s implementation of XP:

• Communication: Developers, customers, and other stakeholders are all part of a team that communicates face-to-face daily and collaborates on everything — from writing user stories to writing code. Communication is a key factor in developing the right solution to any problem.
• Courage: XP operates in a culture of transparency, with team members telling the truth about estimates, status, obstacles, and mistakes. Team members don’t make excuses or blame others, but instead focus on solving problems. The team fears nothing, because nobody ever works alone.
• Feedback: XP calls for short development cycles that produce frequent program iterations, so the team can demonstrate the software early and often and obtain regular feedback.
• Respect: Everyone involved in product development does her job in a culture of mutual respect. Developers and customers respect one another, while management respects the team’s authority over its own work.
• Simplicity: XP is a minimalist approach to programming. Developers are encouraged to “do what is needed and asked for, but no more” to optimize return on investment (ROI). XP programmers should always ask themselves, “What’s the simplest thing that could possibly work?” They take small steps and address challenges as they arise.

Following XP’s software engineering practices

XP’s creators combined XP’s values with a dozen practices that the team commits to over the life of the project. Some of these practices are just for the development team, while others include the customer and other stakeholders. Here’s a list of XP’s software engineering practices:

• The planning game: A quick, high-level activity that determines the scope of the next release by discussing business priorities along with technical estimates. The plan is not designed to be written in stone. If something changes, the team should update the plan.
• Small releases: Start with a simple system and then build up new versions in smaller future releases. Don’t go for a Big Bang product delivery. Instead put something small into production and then look for ways to improve.
• Metaphor: Help the development team understand the whole system by creating a shared story of how everything should work together. Use metaphors such as shopping carts, checkout lines, and parking lots to describe complex technical concepts.
• Simple design: Don’t set out to develop something complex. Instead focus on creating the simplest system and then build in complexity only when absolutely necessary. Always look for ways to remove extra complexity from the system.
• Testing: A big part of the programmer’s job is to write his own tests, which the product must pass with every update to the system. Customers should also write tests to verify that the features meet their expectations.
• Refactoring: Programmers should expect to restructure the program to remove duplication or to simplify or add flexibility to the whole system.
• Pair programming: Programmers develop software in pairs, with two programmers in front of a single workstation. One programmer “drives” (writes the code) while the other observes, navigates, makes suggestions, and checks the work. The two switch roles frequently.
• Collective ownership: Anyone on the team can change code for the whole system at any one time. Parts of the product shouldn’t be hidden or inaccessible to the programming team.

• Continuous integration: The team should use a server to automatically integrate new code and build the program several times throughout the day, each time a major task is completed.

  Partly because of the influence of XP, most agile teams now use something called a continuous integration server. This server allows the entire team to check in and check out all or parts of a software product in a centralized code repository. The server automates the process of testing the software when you check in any new code. This improves quality by ensuring that changes don’t “break the build.”

• 40-hour week: Programming is a creative problem-solving skill. You can’t increase productivity by having your team work overtime. No one on the team should work more than 40 hours per week. Never have the team work overtime two weeks in a row.
• Onsite customer: The team requires that customers participate with the developers and are available full time to answer questions. They should be part of the team and share some responsibility for delivering the product.
• Coding standards: All of the code should be written to help emphasize communication and collaboration. Individuals shouldn’t write code that only they can recognize.

Noting the similarities between XP and Scrum

After publication of the Agile Manifesto, XP and Scrum started to become more similar as teams adopted whichever practices worked best for them from the two frameworks and from others. Similarities between XP and Scrum include the following:

• Continuous integration: Continuous integration got its start long before XP, but it quickly became an integral part of XP, due to XP’s focus on making continuous, incremental improvements to products. Now, continuous integration servers are widely used in nearly every agile framework.
• Planning poker: Both XP and Scrum adopted planning poker as a way to estimate job sizes early in their development.
• Product owner versus customer representative: While Scrum has a product owner who represents the customer and maintains the product backlog, XP has a customer representative who is much more directive, telling the team what it should work on during the next iteration. Both of these roles own the “what next” prioritization for the team’s work.
• Scrum Master versus XP Coach: Both XP and Scrum require that every team have a servant-leader coach. Scrum refers to this role as Scrum Master, whereas XP uses the term “XP Coach.”
• Sprints versus iterations: Both XP and Scrum develop software through a series of short development cycles. Scrum focuses on the cycles themselves (the sprints), whereas XP focuses on the product delivered at the end of each cycle — the program iteration.
• Test-driven development: Test-driven development (TDD) has been around since the 1960s, but was given a rebirth in XP, where the manual approach became automated. Now, TDD is common practice among all agile frameworks.
• User stories: While XP introduced the user story as part of its planning game, almost all agile teams rely on user stories instead of detailed requirements documents.

The most important distinction between XP and Scrum is that Scrum is a product delivery framework, which means you can use Scrum to deliver products that aren’t software. XP is explicitly for software development; it prescribes specific software development practices, such as continuous integration, simple design, and pair programming. Scrum can include these practices but doesn’t explicitly require them.

Mixing and matching agile frameworks

Some of the enterprise agile frameworks mix elements from both Scrum and XP. The Scaled Agile Framework® (SAFe®), discussed in Chapter 4, goes one step further and creates its own agile team referred to as ScrumXP — similar to a Scrum team but incorporating many of XP’s software engineering practices.

Since the Agile Manifesto, proponents of XP have done a great deal to increase its footprint. In Extreme Programming Explained: Embrace Change, Second Edition, Kent Beck includes new sections on the philosophy behind XP and some techniques for scaling. He also ties XP together with the Toyota Production System and Lean Software Development — some of the earlier ideas that led to Kanban and Lean Startup, discussed later in this chapter.

Most of XP’s contribution to enterprise agile has been at the team level, because its focus on software development has prevented it from becoming an attractive option for overall organizational change.

Using a build-measure-learn feedback loop

Lean Startup uses a build-measure-learn feedback loop based broadly on the plan-do-study-act (PDSA) cycle that was originated by Walter A. Shewhart and championed by W. Edwards Deming and influenced Lean Manufacturing, Scrum, and XP:

• Plan: Specify objectives
• Do: Implement the plan
• Study: Gather and analyze data
• Act: Adapt your process based on what you learned

The PDSA loop is an empirical process that emphasizes experimentation and evaluation, and you can see its influence on many agile frameworks, including Scrum, Lean Software Development, and XP.

Lean Startup modifies the loop slightly to emphasize learning (see Figure 2-2):

• Idea: Your customer has a need and you have an idea to meet that need.
• Build: You build a specific solution that has an impact on meeting that need.

• Product: You create a minimum viable product (MVP) — a product with just enough features to appeal to early adopters.

  Many agile software teams use the MVP model, although they may refer to it as something else, such as a “product increment.” In Lean Startup, the MVP offers the most opportunity for validated learning with the least amount of effort. For example, if you were considering opening up a restaurant, you may start with a sandwich stand to test the demand for your sandwiches and to fine-tune your recipe to the consumer’s tastes.

• Measure: You measure the impact that your product had on your customer.
• Data: You create a list, based on your measurements, of actionable data points.
• Learn: You compare your data points to the original plan and figure out what you need to change to improve value to the customer.

Focusing on the one metric that matters

Lean Startup relies heavily on metrics as a way to learn, which doesn’t mean you should bury yourself in data or fall victim to analysis paralysis. Instead you should focus on the one metric that matters (OMTM). Remember that you’re trying to work with an MVP, which should provide you with a minimum number of data points to analyze. For example, if you have a sandwich stand, you don’t necessarily need to examine the various condiments people order; you may need to know only which sandwich seems most popular.

You pick a single OMTM at a time, measure the results, learn from the data, and make improvements. Then, repeat the process in the spirit of continuous improvement.

Mixing Lean Startup with enterprise agile frameworks

Although Lean Startup is a separate and distinct agile framework, you can see elements of it in many agile frameworks and in the enterprise agile frameworks covered in Part 2. All agile teams engage in experimentation and deliver software iteratively in small product increments that result in short feedback loops that drive continuous improvement. In many ways, agile teams function as small startups. Their objective is to get working products in the hands of customers and then learn and adapt along the way.