The Art of Agile Development

by James Shore

Stories represent customer value and are described in customers’ terminology. They describe work that customers recognize and value, not implementation details. This allows your on-site customers to make informed prioritization trade-offs.

One practical result of customer-centric stories is that you won’t have stories for technical issues. There should be no “Design domain layer” story, for example—customers wouldn’t know how to prioritize it.

For example, if you have a story to “send an email when wire transfer completes,” programmers might say it involves the following tasks: Register callback with banking service Log webhook calls Secure webhook Parse webhook transaction data and query database POST to transactional email service Turn them into stories by restating them in business terms: Tell bank to notify us when wire transfer completes Log wire transfer notifications Prevent forged wire transfer notifications Look up customer associated with wire transfer notification Send email to customer when wire transfer notification received

anything that requires the team’s time and isn’t part of their normal day-to-day work needs a story.

Bug stories can be difficult to size. Often, the biggest timesink when debugging is figuring out what’s wrong, and you usually won’t know how long that will take until you’ve done it. Instead, put a timebox around it:

Performance, scalability, and stability—nonfunctional requirements—should be scheduled with stories, too. Like all stories, they need a concrete, customer-valued goal. Unlike other stories, though, you’re likely to need developers to help define the goal. It’s not enough to say, “the software needs to be stable” or “the software needs to be fast.” You need to be able to describe exactly how stable or fast it should be.

When creating nonfunctional stories, think about acceptable performance—the minimum necessary for satisfactory results—and best possible performance—the point at which further optimization adds little value.

Like bug stories, nonfunctional stories can be difficult to size. You can use timeboxes for them, too.

Agile teams are expected to work in a way that allows them to continue indefinitely, and this includes having enough slack in their schedule to constantly improve their codebase.

Don’t create stories for activities such as the planning game, all-hands meetings, and other organizational overhead.

Don’t confuse “valuable increments” with “potentially shippable increments,” another common term in the Agile community. Potentially shippable increments are about a team’s technical ability to release changes. Valuable increments are about changes that actually make an appreciable difference to your business.

Focus on small, valuable increments. Focus on releasing one at a time. Focus on the most valuable ideas first. After each release, take advantage of any new information you’ve learned, adapt your plans, and Focus on the highest value that remains.

Metaphorically, WIP rusts away. It either has to be maintained, reworked, or thrown away, and that’s wasteful. Keep it to a minimum.

an adaptive team will achieve its purpose even though it won’t be able to say exactly what it will deliver.

Adapting your plans requires that your organization think of success in terms of value rather than “delivered on time, on budget, and as specified.”

That’s what the planning game is. It’s a cooperative game designed to create the best possible payoff.

The planning game is notable for the way it maximizes the amount of information contributed to your plan.

Kick off the planning game by reviewing the team’s purpose, then describing how the increments you’ve chosen fit into the overall plan and why they are the most important to do first. Explain what makes the increments valuable and what needs to happen before they can be released, and answer any team questions.

The stories are “just right” when the whole team can finish four to ten per week, or about six on average.

Try to create a plan that allows you to release at any time. You don’t have to actually release all the time, but you want to be able to release at any time, even in the middle of working on an increment.

To keep your options open, build your plan so you can release after every story. Stories can build on previous stories, but they shouldn’t depend on later stories.

In general, customers tend not to know what’s easy, and they end up creating stories that are difficult to implement. Similarly, developers tend not to know what customers think is important, and they end up creating stories that aren’t valuable.

users often think in terms of improving their existing way of working, rather than in terms of finding completely new ways of working. This is another reason why end users should be involved but not in control.

On-site customers—team members with the skill to represent buyers, users, and business stakeholders—are responsible for answering questions about requirements. They act as a living requirements document for the team. They communicate with the rest of the team via conversations, examples, and whiteboard sketches. This is faster and less error-prone than handing off documents, especially for complex topics. When developers need to understand a requirement, they just ask.

If your on-site customers aren’t experts, then they need to facilitate conversations between the team and the experts, so everyone on the team can learn directly from the source.

If your software doesn’t have any product documentation, you may still want to document what it does for the team’s future reference. It’s best to do so as part of each story, when people’s memories are fresh, as part of your team’s definition of “done.”

Operations documentation, also called runbooks, describes standard practices and procedures for a variety of situations, such as deploying the software, responding to alerts and outages, provisioning additional resources, and so forth.

Software development dies in inches. At first everything’s fine: “I’ll be done with this task once I finish this test.” Then you’re limping: “I’ll be done as soon as I fix this bug.” Then gasping: “I’ll be done as soon as I research this API flaw…no, really.” Before you know it, it’s taken you two days to finish a task you expected to take two hours.

Longer iterations won’t change the amount of time you have; they change only how often you check your progress.

If you have trouble finishing everything by the end of the iteration, it’s not because you need more time; it’s because you need more practice working incrementally. Shorten your iteration length, make your stories smaller, and focus on solving the problems that prevent you from finishing stories.

Some teams assign stories to individual team members to work on independently, but the best Agile teams “swarm” their stories. They tackle one story at a time, or as close to one at a time as they can manage, coordinating and collaborating so that everything comes together. By doing so, they avoid the risk of one person getting stuck and derailing progress without the rest of the team knowing.

Creating your task plan should take less than 10–30 minutes. If it takes longer, you’re probably going into too much detail.

If there’s a question you’re getting stuck on, don’t solve it during the meeting. Instead, add it as a design task of its own. For example, if people are trying to decide which authentication library to use, add a task that says “choose authentication library.”

Tasks aren’t assigned to specific people. Instead, when somebody’s ready to start working on a task, they look at the tasks available and choose the next one that they can contribute to or learn from.

It’s easy to fixate on your own tasks at the expense of the team’s overall progress. Remember to stay aware of the broader picture, and to put the success of the team over finishing your individual tasks.

when choosing stories for task planning, don’t choose stories with unfulfilled dependencies. If you’re using iterations, they have to wait until the next iteration.

If you start work on a story and discover that it has a dependency, it’s okay to leave it in your plan. But put a short timebox on it, such as a day or two. If the dependency isn’t resolved by then, take it out of your plan and replace it.

Some stories might need work from your team, work from another team, and then work from your team again. Split those stories into two stories: first, a story to prepare for the other team, and second, a story that you start after the other team has made its contribution.

commitments are a choice the team makes for itself. Agile teams own their work. Managers, never force commitments on your teams. It doesn’t end well.

When you discover a problem that threatens your iteration commitment, see if there’s any way you can change your plan to meet your commitments. Would using some of your slack help? Is there a task you can simplify or postpone? Discuss your options as a team and revise your plan.

Sometimes the problem will be too big to absorb. In this case, you’ll usually need to reduce the scope of the iteration. Typically, this involves splitting a story and postponing part of the work, or removing a story entirely.

If you don’t plan on finishing a story immediately in the next iteration, strip its code out of the codebase and put the story back in the visual plan. If you do plan on finishing the work, create a new story that represents the work that’s left to be done. If you’re using estimates, give it a new estimate.

Sometimes, despite your best efforts, you could end up with nothing that’s completely done. Some teams declare a lost iteration when this happens. They roll back their code and start over as if the iteration never happened.

you’re in the middle of finishing a story, everything is going well, and then a stakeholder says, “We really need to get this new story in.” What do you do? First, decide as a team whether the story is really an emergency. Your next task planning meeting will typically be just days away. Rather than inserting chaos into the team’s work, maybe the new story can wait until the next opportunity.

For iterations, you can remove any story that hasn’t been started and replace it with a story of the same size.

the tasks in our plan depend on code that other people are still working on. What should I do? You can write code that depends on unfinished code. Talk to the people who have the other task and come to an agreement about module, class, and method names, then stub in the part they’re working on.

Capacity is a prediction of how much the team can reliably accomplish in a single iteration.

Customers want the team to deliver more every week. Developers don’t want to be rushed or pressured. Because customers often have the ear of the team’s sponsor, they tend to win…in the short term. In the long-term, when teams are pressured to commit to more than they can deliver, everyone loses.

Excessive schedule pressure universally reduces teams’ performance. It causes them to rush, take shortcuts, and make mistakes. Those shortcuts and mistakes hurt their internal quality—code, automation, and infrastructure quality—and that poor quality causes everything to take longer, ironically giving them less time to do their work. It’s a vicious cycle that further increases schedule pressure and decreases performance.

Some estimators try to figure out all details of a story before making an estimate. Remember that the only details that matter, during estimating, are the ones that would put the estimate in a different bucket. Focus on the details that would change the estimate and save the rest for later.