Make Your Software Useful

Take one more look at that quote from Ken Schwaber at the beginning of Chapter 4. If you don’t get collective commitment, you don’t get Scrum. But what does that term, “collective commitment,” really mean? What, as a team, are you committing to together?

Collective commitment means genuinely trying to make your software more useful. To make your software useful, you need to understand what it is that your users are doing. You have to truly care about helping them do whatever it is that they do—and you need to care about improving that aspect of their lives more than you care about any other aspect of the project.

This is built right into the Agile Manifesto. Think about what it means to build “working software”—how do we actually define “working”? It’s trivial to make software that simply runs. It’s not hard to build software that looks like it “works” but which drives the users crazy when they actually attempt to do their jobs with it. But building actual “working” software means building software that really helps the users get their work done. And the most effective way that we have of building working software is customer collaboration. This is another reason that we value working software over comprehensive documentation, and customer collaboration over contract negotiation.

Before agile changed the world of software development, teams routinely built software that was not useful, and we have plenty of evidence of this. Open up practically any academic textbook on software engineering written in the late 1990s or early 2000s, and you’re likely to find a reference to the Standish Group’s CHAOS report. The Standish Group started doing this report in the mid ’90s in response to a perception—which happened to be true—that a huge number of projects failed (around a third of them were considered successful, as it turned out³⁰). Their annual survey and study repeatedly found that project teams felt that many features in the software they built were not used. The 2002 study³¹ put this figure at an absurdly high 64% (45% never used, 19% rarely used).

This may have been a shock to many in the academic community, but to a lot of software teams at the time, it was obvious. In fact, what the CHAOS report defined as “failure” was so common that many teams considered it a basic fact of software development. Teams would build software, throw it over the wall to their users, and hopefully some of what they built would stick. Many discussions (arguments) with users ended with a developer saying, “It’s not a bug, it’s a feature.” This was a way for the developer to say that the software works exactly the way he intended it to work, and that the user needs to change his expectations to match it. This is a lousy way to treat users.

Roger and Avi ran into trouble with their achievement editor because they built a complex, over-engineered tool to solve a simple problem. This is a very common way for teams to build software that isn’t as valuable as it could be. In fact, it’s so common that there’s a term for it: gold-plating. Teams gold-plate their software, or add extra features that were never requested and aren’t needed by the users, with the best of intentions. Developers want to help, and they think that what they’re building is really cool and will be very valuable. This is a very natural thing for an excited developer to do, and it’s one of the main sources of those 64% of features that go unused.

Another contributor to that high number of unused features is the throw-it-over-the-wall mentality itself, because users feel like they have a limited time to work with the development team and will sometimes try to fit in as many feature requests as possible within that time. That can lead to stakeholders actually requesting features that are of little value when they’re delivered.

Effective agile teams, however, rarely have this experience. It’s rare for any feature of the software they build to go unused, much less two-thirds of them—so much so that people on those teams often see the conclusions of the CHAOS report as incorrect. In fact, it’s not uncommon to hear the CHAOS report results snarkily referred to as “debunked” by some agile evangelists. So what are effective agile teams doing that allows them to build such useful software?

User Stories Help Build Features Your Users Will Use

Agile teams start by getting into their users’ heads, and they have a very effective tool for doing that. A user story is a deceptively simple tool. It’s a quick and simple description of a specific way that a user will use the software. Most user stories are between one and four sentences long—most teams have a rule of thumb that a user story has to fit on the front of a 3×5 index card.

Many teams write their user stories in a specific, Mad Libs–style, fill-in-the-blanks format:

• As a <type of user>, I want to <specific action I’m taking> so that <what I want to happen as a result>.

Here’s a user story that the Lolleaderz.com team might have used as a starting point for the achievement feature.

Figure 5-2. A user story written on an index card.

This user story is effective because it makes three important things obvious:

• Who the user is: “a returning user with a large friends list”

• What the user wants to do: “nominate one friend’s video for an achievement”

• Why the user wants to do it: “so that all of our mutual friends can vote to give him a star”

It also has a title (“Nominate a video for an achievement”), which gives the team an easy way to refer to the user story when they’re talking about it.

This is a lot of information packed into the user story. It means that there are many things that have to be built: user interfaces for nominating and voting, a way to store nominations and votes, an update to the system that displays the video to look for achievements and display a star, and probably several other things.

What’s just as important is what isn’t there. There’s nothing about any sort of criteria editor (like the team added unnecessarily), or other unnecessary features. This is why a user story is an effective tool for fighting gold-plating. What happens if the team writes down user stories, goes over them with the Product Owner (and users, stakeholders, and anyone else who has a good opinion to share), and sticks to them? If they do this, they’re a lot less likely to bloat the software with features that the users don’t need and won’t use.

User stories also give teams an easy way to manage their backlog. Many effective agile teams maintain a backlog that consists almost entirely of user stories. Because each user story is simple and written from the user’s perspective, it’s easy for the Product Owner to review the stories with the users and stakeholders in order to figure out which stories are the most valuable. And each story is very small, which makes it easier to add new ones or change their order at any time. When it comes time to start a sprint, the Product Owner and the team can pull some of the stories out of the backlog and designate them as to be delivered in this sprint.

The team can then discuss the stories with the Product Owner to make sure there is clarity on what the stories mean, and how they will know when each one is done. Most teams will then break the stories down into tasks and start to estimate how long those tasks will take. The tasks for each story would go in the “To Do” column of the task board to wait until someone can work on them. When a team member is ready to take a new task, he or she will select the next most valuable task they could do, write their name on it, and move it to the “In Progress” column to indicate that they are taking the task.

Conditions of Satisfaction

One way to be sure of what you’re building is to be able to envision what it will look like when it’s done. It’s very satisfying for a developer to take a step back, look at what he or she just built, and feel like it’s finished. Conditions of satisfaction are an effective tool for helping developers to know what the software will look like when it’s complete, and to gauge how close they are to done. (Some teams refer to conditions of satisfaction as “acceptance criteria.”)

Conditions of satisfaction, like user stories, seem really simple but accomplish a complex goal. Most teams define them for each user story by writing down some specific things that the user needs to be able to do with the software once the user story is written. Typically, the conditions of satisfaction can fit on the back of the same 3×5 index card as the user story. The Product Owner usually has a hand in writing the conditions of satisfaction or at least reviews them when they’re written.

Conditions of satisfaction for the “achievements” user story might look like this:

Figure 5-3. Conditions of satisfaction written on the back of the user story index card.

These conditions are valuable to developers because it helps them avoid declaring victory too early. It’s not uncommon for a programmer to build many of the pieces of a feature, but put off the finishing touches until the end of the sprint. For example, he might build out the pages to do the nomination and modify the code that displays the video to add the star for achievements. But until he ties it all together so that every link is in place and all of the new code is fully integrated into the existing codebase, the feature isn’t done—and it’s a lot more efficient for him to finish building the story now while it’s fresh in his mind.

Conditions of satisfaction help this by giving the team a concrete definition of “Done.” This gives the team and the Product Owner a concrete, unambiguous way to figure out exactly when that story is “Done.” To call the story “Done,” all of the work it takes to understand it, build it, test, and deploy it must also be done. The user story is “Done” when a user can open up the working software, and execute each of the conditions in exactly the same way that it would be demonstrated in the sprint review. Until the team member can do this, the user story isn’t done, and he stays focused on that user story (remember the Scrum value about everyone being focused on the work?) until it’s done. And as soon as it’s done, he moves it from the “To-Do” column of the task board to the “Done” column. Done!

Story Points and Velocity

During sprint planning, your whole team works together to figure out how much work they can do in the sprint, so that they can set a goal for the working software that will be delivered at the end. But how, exactly, does the team do that?

There are practically as many ways to estimate how much work a team can do in a sprint as there are teams. One technique that has proven especially effective for Scrum teams over the years is to use story points. Story points are a way to understand how much effort you’ll need to build a specific user story by assigning a number of points to it. The team comes up with those points by comparing the current user story to other stories your team has built in the past.

While there’s no hard-and-fast rule about how many points to assign to each story, some teams assign between 1 and 5 story points to any user story. (The 5 value is arbitrary—other teams will give stories between 1 and 10 points, or use another number, as long as they use a consistent rule from sprint to sprint. Still other teams use numbers from the Fibonacci sequence, or exponential numbers. You can pick any scheme that works, as long as everyone on the team is comfortable with it.) One 3-point story should require about as much work as another 3-point story. As your team assigns points to all of the stories they work on, they start to see how many points’ worth of stories they can complete (or “burn”) in a sprint. If your team completes on average, say, 25 points’ worth of stories in a sprint, then their project velocity is 25 points per sprint.

Teams tend to work at a pretty constant velocity when measured across many sprints. So while it’s hard to predict what your project velocity will be before you start working with a team, you can use the velocity from past sprints to help you plan for the next one.

Now, anyone who’s had to manage their retirement account has read the disclaimer, “Past performance is not a guarantee of future returns.” The same goes for story points. Even if your team burned 32 points last sprint and 29 the sprint before, there’s no guarantee that they will burn around 30 this sprint—in a given sprint, people will misjudge certain stories, run into unexpected technical problems, go on vacation, quit, or have other life events that interfere with the project. But despite that, story points and project velocity are a surprisingly reliable guide for most Scrum teams over time, and you can take advantage of that reliability when you plan your sprint.

A sprint planning session using story points might go like this:

1. Start with the most valuable user stories from the product backlog.

2. Take a story in that list—ideally the smallest one, because that makes a good baseline for comparison—find a similarly sized story from a previous sprint, and assign it the same number of points.

3. Discuss with the team whether that estimate is accurate—discovering additional problems, work, or technical challenges increases the estimate; simplifying factors, reusing existing code, or scaling back what needs to be built decreases the estimate.

4. Keep going through the stories until you’ve accumulated enough points to fill the sprint.

Don’t overload your sprint backlog. It’s OK to leave room in the backlog, but it’s not OK to go beyond what your team has done in the past. If your team has an average velocity of 28 points per sprint, and you’ve already put 26 points’ worth of stories into it, then you can only add a 2-point story or two 1-point stories. Because developers are very optimistic by nature—we have to be, because we’re builders—the team will be tempted to add a 3-point story and just go over by one point. Don’t give in to that temptation; it’s a good way to disappoint your users at the next sprint review.

What about the first time you do this? It takes time to build up a history of stories, and to build up the common knowledge among your team about how big a 3-point story is. So for the first time through, just take a guess. Choose one story that seems to be about the middle of the road in terms of work, and arbitrarily assign it 3 points. Find the biggest story that’s valuable, and assign it 5 points. Find the smallest one, and assign it 1 point. Use these as a starting point for estimating more stories and filling up your sprint. By the time you’ve gone through two sprints, you’ll have plenty of stories to compare to, and a good idea of your team’s average velocity.

Burndown Charts

A burndown chart is a way for anyone to see, at a glance, how the sprint is actually progressing when compared with the team’s past velocity.  Here’s how to build a burndown chart based on story points (this also works with other units of measurement, like hours, but we’ll use story points):

1. Start with an empty line chart. The x-axis has dates, starting with the first day of the sprint and ending with the last day. The y-axis has story points, ranging from 0 to 20% more than the total number of points in the sprint backlog. Draw the first dot on the chart: the number of points in the sprint, at day 0. Draw a straight line (called the “guideline”) from the first point to the end of the project—zero points left when the sprint is complete.

   

   Figure 5-4. Burndown chart when the sprint starts. We created this burndown chart using story points, but you can also use hours, days, or another unit of measurement.

2. As soon as the first user story is finished and moved to the “Done” column of the task board, draw the next dot on the chart: the number of points left in the sprint, at the current day. As you finish more stories and burn more points off of the backlog, fill in more days in the burndown chart.

   

   Figure 5-5. Two stories worth 7 points burned off

3. You might discover during a Daily Scrum that more work needs to be added. Sometimes you’ll do this because the team is burning more points than they expected, and they’ll finish early as a result. Or an important support task comes in, and the team and product owner agree that it needs to be added to the sprint, but they don’t yet know how much work the team will need to remove to balance out the sprint. When you add the cards for that work to the task board, schedule a follow-up meeting to gather up the team, estimate the story points for each card, and add them to the chart. It’s helpful to draw an extra line that shows where the points were added—and don’t be afraid to write notes on the chart!

   

   Figure 5-6. The Product Owner added stories halfway through the sprint.

4. As you get close to the end of the sprint, more and more points burn off the chart. Keep an eye out for a gap between the guideline and your actual burndown, because that could mean you’ve got too many points left in the sprint and need to remove a user story.

Figure 5-7. A gap between the burndown chart and the guideline tells you that there’s a good chance you won’t finish all of the stories by the end of the sprint.

There are lots of great software packages that let you manage your backlog, stories, and story points, and draw burndown charts automatically. However, many teams prefer to draw burndown charts by hand, and keep the chart on the same wall (often on the same whiteboard) as the task board. This lets everyone see exactly how the project is doing at any time. It’s especially satisfying for the team if each developer gets to update the burndown chart after he or she completes a user story and moves the card to the “Done” column.

Planning and Running a Sprint Using Stories, Points, Tasks, and a Task Board

If you read the description of sprint planning in the Scrum Guide (or in the beginning of Chapter 4), you’ll see that you need to have a sprint planning meeting to come up with detailed answers to two questions:

• What will the team deliver in this sprint?

• How will the team do the work?

We just showed you how a team can use story points and velocity to figure out what will go into the sprint. That’s a very common way for Scrum teams to handle the first half of sprint planning. But how do they actually plan out the work in the second half?

One of the most common ways for Scrum teams to plan out the actual work for the team is to add cards for individual development tasks. These tasks can be anything that the team actually does: write code, create design and architecture, build tests, install operating systems, design and build databases, deploy software to production servers, run usability tests, and do all of those other things that teams actually do every day to build and release software.

Here’s how many teams do this:

1. The team holds the second sprint planning meeting. The Scrum Master starts with the first story, and leads a discussion with the team about exactly what they need to do to build it. Everyone works together to come up with a list of individual tasks that they think will each take no more than a day to complete. Each task is written on a separate card—some teams use different colored cards for stories and their tasks to make it easier to tell them apart—and the story card is grouped together with its task cards. This continues until all stories are planned. If the sprint planning timebox expires before all of the stories are broken down, each unplanned story gets a single task card for a task to plan out the story.

   

   Figure 5-8. The second half of the sprint planning session is all about breaking the stories down into tasks that the team members will do during the sprint.

2. The stories and their tasks are grouped together and added to the “To Do” column of the task board.  

   

   Figure 5-9. Each story card in a sprint is grouped together with the cards for its tasks and added to the “To Do” section of the task board.

3. When a team member finishes one task and is ready to move on to the next, he moves the task card for the completed work to the “Done” column. Then he pulls the task card for the next piece of work out of the “To Do” column, writes his name on it, and then puts it back on the board in the “In Progress” column. If the story is still in the “To Do” column, he moves it to “In Progress” as well (but doesn’t write his name on it because one of his teammates might work on tasks for the same story).

   

   Figure 5-10. Each team member works on exactly one task at a time by writing his or her name on its card and moving it to the “In Progress” section of the task board.

4. As the sprint rolls along, the team moves tasks from “To Do” to “In Progress” to the “Done” column. It’s pretty common for team members to discover that they need to do additional tasks to finish a story. When this happens, the new task is added to the board, and the team member points that out in the Daily Scrum so everyone is aware of what’s going on, and can help spot potential problems.

5. Once a team member finishes the final task for a story, he pulls the story card off of the task board, verifies that all of the conditions of satisfaction are completed, and moves it to the “Done” column so that it’s grouped with all of its tasks. (But remember—the story’s not done done until the Product Owner accepts it as potentially shippable on behalf of the company!) If he discovers that one of the conditions of satisfaction hasn’t been met, then there’s still work to be done—so he moves the story back to the “In Progress” column and adds tasks to complete that work to the “To Do” column.

   

   Figure 5-11. When a team member finishes a task, he or she moves it to the “Done” section of the task board and claims another task—and if all of the story’s conditions of satisfaction are met, the story card is moved to the “Done” section too.

6. The sprint is done when the timebox expires. This means that there might still be story and task cards left in the “To Do” and “In Progress” columns. The stories go back to the product backlog so they can be prioritized in the next sprint planning session,³³ but the team can reduce the number of points based on the tasks that remain. The team does not get credit for completing a story until its card and all of its task cards are moved to the “Done” column.

Generally Accepted Scrum Practices

If you search Ken Schwaber’s original book on Scrum, Agile Project Management with Scrum, you won’t find any mention of user stories or story points. Many teams learned about them from other sources, like Mike Cohn’s excellent book, User Stories Applied.³⁴

There are many great practices that teams use to improve how they use Scrum. This shouldn’t be a surprise. The whole reason we have retrospectives is to find ways to improve what we’re doing. If we decide that we’re bound to what one person wrote in a book, and refuse to go beyond what’s written in it, why bother finding ways to improve?

This is why many teams make use of additional tools and techniques, which Cohn termed Generally Accepted Scrum Practices (GASPs).³⁵ For example, many teams find that their Daily Scrum meetings are more effective when held as a standup meeting, where everyone stands until the meeting is complete. This is not a core Scrum practice, but it’s accepted by many Scrum teams.

Remind yourself of the last principle in the Agile manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

You and your team should keep this in mind when you hold your retrospectives. Try to find ways to improve, but don’t reinvent the wheel. If you’re running into a problem with Scrum, the odds are that someone else also ran into it at some point. If you have a good mentor (like Roger and Avi have Eric), he or she should be able to help you find a change or a practice that will help fix the problem.

Practices Do Work Without the Values (Just Don’t Call It Scrum)

Not every team in every company can self-organize from day one, and that’s OK. If your company’s culture doesn’t match the Scrum values, then your job as a Scrum adopter is to help the people around you understand its values. The best way to do this is to lead by example: show everyone around you what it means to be open about your work, have respect for others on your team, and show courage when you run into problems. Finding a good mentor is a great way to show people that this can really work, and help people start to change their attitudes. Often, teams will bring in a consultant as a mentor because it’s easier for their bosses to listen to someone from outside the company tell them that they need to make changes.

But sometimes, even if you do everything right, the prevailing culture of the company where you work might be too far away from the Scrum values. If that’s the case, self-organization and collective commitment might simply be out of reach for your team. And as Ken Schwaber showed us, if you don’t get self-organization and collective commitment, you don’t get Scrum.

And that’s OK!

Even without the “heart and soul” of the values, and even without self-organization and collective commitment, Scrum still has some pretty great practices. They’re very simple, easy to implement, and can generally be done inside the team without your asking permission (or apologizing later).

If you recognize that you’re in an environment where you can put the practices in place but not the values, then you can still get better-than-not-doing-it results. And because it’s better than not doing it, you should do it! Just make sure that you and your team recognize what you’re doing, and where your boundaries are.

However, don’t just adopt the practices and then call it a complete Scrum adoption. If you do, you’ll set yourself up for a struggle later on. People in your company who have read about “hyper-productive teams” and “astonishing results” will question why you’re not getting those results, and you won’t have a good answer. Even worse, your team will probably get excited about Scrum, only to find that life has just changed slightly for them. In a sense, they’ll get the message that this is the best that they can do, and if that’s not much different than before, that can be frustrating and demotivating. These problems can poison future attempts to improve: by setting the bar too low, they assume that they’re facing limitations outside their control.

In other words, by telling everyone, “You’ve done Scrum, congratulations!” you give the impression that Scrum is nothing more than renaming your status meeting to a Daily Scrum and your requirements to a backlog. That’s dangerous for you, as an eager agile adopter, because the fundamental problems you were trying to solve in the first place by implementing Scrum still exist, so most people will assume that Scrum can’t fix them—and, worse, that those are problems that exist everywhere and simply aren’t fixable by humans. Think about how many times you’ve heard someone say something like, “Developers can’t estimate,” or “Software is always buggy,” or “Projects always run late,” as if those are basic facts of life that can’t be changed.

The worst part is that when you constantly claim Scrum can solve problems that clearly haven’t been solved and that people assume can’t be solved, you start to come off as a pushy agile zealot. People will get sick of hearing about Scrum but not seeing any results. That hurts your career, and it ruins the idea of Scrum for all of the people around you.

There is another way!

Give your team new practices that they can do today, but also give them a vision of what they can accomplish tomorrow. Then they won’t just assume that they’re doing Scrum because they’ve adopted a few simple practices.

What if you openly acknowledge that you’ve put in place the Scrum practices, but you haven’t started to work on self-organization or collective commitment yet? Instead of claiming that a “practices-only” Scrum implementation is complete, we can be honest with our teams that we’re putting in place the practices, but that we still have a long way to go with the values, with self-organization, and with becoming genuinely committed to delivering value.

The first difference with that approach is that you haven’t made any promises that you can’t keep. You told people that you would make things a little better. So when they see better-than-not-doing-it results, instead of being disappointed that you haven’t solved every problem the company will ever face, they’re happy that your team is producing better software, and building it more quickly and easily. It’s much easier to start talking about new values for the company if you have a track record of improvement, even small improvement. And from your boss’s perspective, instead of criticizing him for not being “Scrum enough,” you’re giving him good results today and promising even better results tomorrow—if he’d just let the team go out on a limb with these new values.

Is Your Company’s Culture Compatible with Scrum Values?

Not every company is ready to give up command-and-control project management and start self-organizing, and not every team is ready for collective commitment. The way to figure out if your team and company are ready is to evaluate whether the culture is compatible with the Scrum values. But how do the Scrum values translate into real-life practice?

Ask yourself each of these questions, and try to come up with honest answers. Discuss them with your team, and with your manager. If everyone is really OK with each of these things, then your company and team are ready for the Scrum values. If not, then those conversations will help you figure the right approach to bringing Scrum to your team.

To understand if you’re ready for commitment, ask if you, your team, and your boss are OK with:

• Relinquishing control of the project, and trusting the team to decide what gets delivered?

• Not going off on your own and building something without talking to the rest of the team, and just integrating it at the end?

• Not having one “single, wringable neck?”³⁷

• Listening to comments and feedback, and not telling people to mind their own business?

• Actually being willing to take responsibility? Does everyone on the team feel the same way?

To understand if you’re ready for respect, ask if you, your team, and your boss are OK with:

• Trusting the team to do the right thing, and deliver each feature at the best possible date based on relative value and how the project progresses—even if it causes the project to take longer than you expect?

• Giving the team enough time to do the work, and not demanding overtime of them?

• Trusting the team to choose the tasks that are right for them and for the project, rather than relying on strict roles, RACI matrices, etc.?

• Not being able to ever say again that you don’t know why the team decided to do something the way they did?

To understand if you’re ready for focus, ask if you, your team, and your boss are OK with:

• Never asking anyone on the team to do work that’s not part of the current sprint?

• Never asking anyone on your team to do work that the whole team hasn’t agreed to take on (“but I need this done now!”)?

• Putting what’s most valuable to the company ahead of all other project or work concerns?

• Not being able to demand that team members work on specific tasks in a certain order up front?

To understand if you’re ready for openness, ask if you, your team, and your boss are OK with:

• Listening to what other people have to say—and actually thinking about it?

• Thinking about project planning or users if you never have before?

• Thinking about technical details if you never have before?

• Thinking about what the programmer next to you is working on, and whether it really fits into the overall goal?

• The programmer next to you thinking about your work in exactly the same way?

To understand if you’re ready for courage, ask if you, your team, and your boss are OK with:

• Not being able to blame lack of planning on your project manager?

• Not being able to blame poor requirements that don’t hit the mark on your Product Owner or senior managers?

• Taking the time to really understand your users?

• Building something that isn’t perfect, because what the users need most is something that’s simply good enough?

If the answer to most of those questions is “yes,” then your team, managers, and company probably have a culture that matches the Scrum values. On the other hand, if you’ve answered “no” to more than one or two bullets for any of the values, then that’s a good starting point for a realistic and open discussion with your team and your boss. And if that open discussion sounds unrealistic, then you’re definitely going to have to work on openness if you want to get the most out of Scrum.