14 - Agile

#dev

Class: CSCE-331

Notes:

The Winter Gateway That Turned the Software World Upside Down

How a group of programming rebels started a global movement

Snowbird, Utah, is an unlikely place to mount a software revolution. Around 25 miles outside Salt Lake City, Snowbird is certainly no Silicon Valley; it is not known for sunny and temperate climes, for tech-innovation hubs, or for a surplus of ever eager entrepreneurs. But it was here, nestled in the white-capped mountains at a ski resort, that a group of software rebels gathered in 2001 to frame and sign one of the most important documents in its industry's history, a sort of Declaration of Independence for the coding set. This small, three-day retreat would help shape the way that much of software is imagined, created, and delivered-and, just maybe, how the world works.

Whether or not you recognize its name, you've probably encountered Agile, or at least companies that use it. Representatives from Spotify and eBay confirmed that both companies currently use Agile, and there's a job listing on Twitter's website for an "Agile Coach." Bread-crumb trails across the internet suggest that many other bigname technology companies have at least experimented with it in the past. And it's not just Silicon Valley: Walmart reportedly began experimenting with Agile years ago. The Agile Alliance, a nonprofit that promotes the use of Agile, counts all sorts of corporate giants-including Lockheed Martin, ExxonMobil, and Verizon-among its corporate members.

Agile's acolytes seem to be everywhere, bringing with them a whole nerd lexicon of tools and tricks to make workplaces more efficient: Think daily stand-ups and sprints. Taken at face value, it may seem like another meaningless corporate buzzword used by project-management types. But it's actually a very specific philosophy, one that is outlined in the four-bullet, 68 -word document signed at Snowbird.

Before software could eat the world, it needed to pull itself out of the deluge. Silicon Valley may be one of the only places in the world where the word "Waterfall" has a slightly negative connotation. In programming, Waterfall is used to describe a way of building software-think a slow, trickling, stage-by-stage process. Under Waterfall, the software project is rigorously designed up front, in the way that one might manufacture a wristwatch.

It worked something like this: Someone would dream up a piece of software they'd like built. Before so much as a line of code is written, the creators write out what they want built and how in a series of long, detailed plans. They craft what's called a requirements document, where they outline everything they want the software to do. Projects then flow downstream, from stage to stage, team to team, until they reach completion. At the very end, the entire new piece of software is tested, given back to the customer, and sent out the door.

Many attribute the origin of this model to a 1970 paper by Winston W. Royce-but there's a big catch: Though a Waterfall-like diagram appears on the second page, Royce's paper doesn't actually endorse building software that way.

A linear approach might work when you know exactly what you want to build, but it can be too restrictive for some projects-software development, as Michael A. Cusumano, the Sloan Management Review distinguished professor of management at MIT, puts it, is "really an invention process." "Software engineers or programmers like to go back and forth across those different steps," says Cusumano. "They're not really sequential."

And there's a problem with waiting until the end of a project to test the whole thing, Cusumano points out: If you catch a bug at the last stage, it can be messy-or even fatal-to try to go back and fix it. Some software projects would get and fix it. Some software projects would get stuck and simply never ship.

"People would come up with detailed lists of what tasks should be done, in what order, who should do them, [and] what the deliverables should be," remembers Martin Fowler, the chief scientist at ThoughtWorks, who attended the Snowbird meet-up. "The variation between one software and another project is so large that you can't really plot things out in advance like that." In some cases, the documentation itself grew to be unwieldy. A few of the people I spoke with shared horror stories: an entire bookshelf's worth of requirements in binders or an 800-page document that had been translated across three different languages.

Another Snowbird participant, Ken Schwaber-the cofounder of Scrum and founder of Scrum.org-says Waterfall "literally ruined our profession." "It made it so people were viewed as resources rather than valuable participants." With so much planning done upfront, employees became a mere cog in the wheel.

As the pure sequential model faltered in the 1980s and early 1990s, some companies began experimenting with different ways to work through projects, creating processes that, as the former academic in the field of science and technology studies Stuart Shapiro says, allowed developers to "climb back up the waterfall."

In a 1997 paper on Microsoft, Cusumano and his coauthor Richard W. Selby describe how Waterfall "has gradually lost favor ... because companies usually build better products if they can change specifications and designs, get feedback from customers, and continually test components as the products are evolving."

Around the turn of the century, a few rogues in the software industry began really pushing back. They wanted to create processes that would give them more flexibility and actually allow them to ship software on time. Some of these processes, like Scrum and Extreme Programming (XP), were called "light" or "lightweight" processes. But no one subset had really caught on. So, in 2001, the lightweight guys decided to join forces.

"I think at that point, we were all sort of seeking legitimacy, that we'd sort of been all out on our own doing similar things, but it hadn't really taken off big-time in the community," remembers Jim Highsmith, an executive consultant at ThoughtWorks.

It's unclear who came up with the idea for the meeting that would eventually take place at Snowbird. Many of the participants were leaders in the software community, and a few remember the idea being tossed around at industry meet-ups. When the invitation to the retreat finally arrived, it came via an email, from Bob "Uncle Bob" Martin. Martin, an industry veteran and the founder of Uncle Bob Consulting, runs The Clean Code Blog and has a perfect sense of nerd humor: A YouTube video embedded on his website features Martin, among other things, blasting off on an asteroid. Martin says he and Fowler met at a coffee shop in Chicago, where they composed and sent the email. Fowler doesn't have any memory of their meeting, but says it's "likely" it went down that way.

After running through a few options-like Chicago ("cold and nothing fun to do," wrote Highsmith in 2001) and Anguilla ("warm and fun, but time-consuming to get to")-the group settled on Utah ("cold, but fun things to do"), booking an excursion to Snowbird. There, beginning February 11, 2001, the men-and they were all men -would hit the slopes and talk software processes.

James Grenning, the founder of Wingman Software, remembers a blizzard. "We were snowed in," he says, "and it was like avalanche conditions. No one was going to go anywhere. It was an amazing thing."

There probably wasn't a blizzard. Historical weather data from Dark Sky suggest there was some light snow in the days leading up to and during the retreat. But the weekend did-at least, metaphorically speaking-bury a lot of what came before it.
"I have been in many, many of these kinds of meetings throughout my career," recalls Highsmith. "This one was really special."

I spoke with 16 of the 17 attendees. (Kent Beck, a technical coach at Facebook, declined to be interviewed for this article.) Over a decade and a half later, they reflected on the retreat. "It was one of those things where you think, 'You know, you're gonna get a bunch of people in a room and they're going to chitchat and nothing's going to happen,'" says Martin. "And that's just not what happened. This group of people arranged themselves, organized themselves, and produced this manifesto. It was actually kind of amazing to watch."

Settled at Snowbird, the group began laying out what they had in common. Schwaber recalls, "When we compared how we did our work, we were just kind of astonished at the things that were the same."

Unlike other historical documents, the Agile Manifesto doesn't declare truths selfevident. Rather, it compares: We value this over that.

Ward Cunningham, the cofounder of Cunningham & Cunningham (who is famous in the software community for, among other things, coining the term "wiki"), reflects on that moment. "When it was written down on that whiteboard, some people were out in the hallway on a break," he recalls. "And I was out in the hallway, and [someone] said, 'Come here, and look at this. Look at what we wrote.' And we were just standing around looking at that whiteboard, in awe at how much that summarized what we held in common. It was such a dramatic moment, you know, that instead of everybody talking in small groups, we stood around that whiteboard and studied it."

Cunningham says he jumped on a chair and took a picture of that moment "because I could tell that something profound had happened."

So what is the Agile Manifesto? The preamble reads, "We are uncovering better ways of developing software by doing it and helping others do it." It then lays out the four core values:

The document concludes that "while there is value in the items on the right, we value the items on the left more." Like any good founding document, the words can be interpreted differently, but the basic gist is this: Put people over process. Focus on making software that works, not documents about that software. Work with your client rather than fight over a contract. And along the way, be open to change.

The men finished the Manifesto during the retreat. They spent the rest of the time working on the 12 principles behind the new document and, well, skiing. (Some argue that the principles are considered an official part of the Manifesto; others consider the Manifesto itself just the values.)

This new philosophy needed a name, and not everybody was satisfied with the "Lightweight" working title. "It somehow sounds like a bunch of skinny, feebleminded, lightweight people trying to remember what day it is," Highsmith recalls Alistair Cockburn, another participant, saying. Cockburn, who is today an independent software consultant, remembers facilitating the search for the word. "It wasn't like somebody said, 'Agile! Oh great, let's go,'" Cockburn tells me. "It was really a lot of work." The other finalist, he says, was "Adaptive."

"The only concern with the term 'agile," writes Highsmith in his 2001 summary of the retreat, "came from Martin Fowler (a Brit for those who don't know him), who allowed that most Americans didn't know how to pronounce the word 'agile.'" Fowler eventually got over it-although, after speaking with him on the phone, I couldn't help but notice that he still pronounces the word with a British accent: an elegant ahgile, instead of the American ah-gel.

Many described the debates at Snowbird as surprisingly friendly, especially considering the intensity of the egos in the room. Cockburn recalls "immense generosity in the listening and the understanding for other people."

But not all the participants remember everything so rosily: "The first day had quite a lot of alpha-male-type, status-posturing-type behavior," Brian Marick, an independent programmer and author, recalls, "which made me pessimistic that much good would come out of the meeting." Marick says he called his wife that first evening of the retreat, telling her, "There's a powerful odor of testosterone in this room."

Schwaber says the group did invite "a whole bunch of really pretty knowledgeable women" but that none showed. "They thought it would just be a carousing and smoking weekend," Schwaber says. "They didn't think we were going to do anything intellectual or productive."
"That was a shame," he says, "because there's some people that would've been really helpful." But it's unclear whether women were, in fact, actually invited: A few of the framers tell me they vaguely remember some women being invited. Others don't.

As the men left Snowbird, no one anticipated what happened next. "When I came down the mountain, which I was riding with a couple other Manifesto writers, I was thinking to myself, 'I'm not sure anybody would pay any attention to this,'" recalls Mike Beedle, the CEO of Enterprise Scrum. "My feel was that it was sort of like a gamble. It was like a question mark. Who knows? I mean, maybe people will go to this website that we're proposing putting up. Or maybe they won't."

They did. Unlike the ink-and-paper Declaration of Independence, the Agile Manifesto was born of the internet age. The final document is hosted online, on a simple website that feels straight out of the early 2000s, featuring a bunch of guys in khakis standing around a whiteboard. Cunningham, who continues to host the site, says he intended for people to print the document and hang it up as a poster. But for a decade and a half, the website provided something greater than cubicle art-it stood as a virtual, communal rallying cry. Site visitors were invited to sign on to the Manifesto and publicly add their names to the document.
"We put that thing up, and it just exploded," says Dave "PragDave" Thomas, a coauthor of The Pragmatic Programmer and an adjunct professor at Southern Methodist University. "That site was actually a focal point, if you'd like, for people who want to say, 'Yes, I agree with this.' And I think that's one of the reasons it took off."

Marick agrees. "I think it was really the fact that people could vent their frustration by citing Martin Luther's theses hammered to the door, and they could put their signature on it as well," he says. "That was what really gave it momentum."

The ability to sign the document ended in July 2016. (Cunningham reconfigured the hosting and is beginning to treat the Manifesto like a historical document.) But in the 15 years since it was first published, he says, more than 20,000 people signed the Agile Manifesto.

The Manifesto, of course, was only the beginning. "My gosh, I wish I could've been there," Grady Booch tells me. Booch, the chief scientist of software engineering for IBM Research, was invited to the retreat at Snowbird, but says he bailed at the last minute in order to deal with a "pesky customer." Booch doesn't doubt Agile's seminal origin or its subsequent impact. He tells me that the 1990s were "an incredibly rich time in development in software engineering, when you had literally dozens, if not hundreds, of people that were pioneering new ideas about software development." All of that, he says, "came to a head" at Snowbird.

Unlike Waterfall, Agile emphasizes iterative development, or building software in pieces. Agile teams typically work in short cycles-which are called "sprints" in Scrum, today one of the most widely used forms of Agile-that usually last two weeks each. Booch argues that both Agile and Waterfall are valid approaches, but that different projects call for different methods-and it's important to weigh factors like the project's risk and the culture of the team that's executing. "If I'm building a nuclear-power plant," he says, "believe me, I don't want to use incremental and iterative methods because testing failure is never a good thing; it's kind of irreversible. On the other hand, if I'm building a throwaway app for some new clone of Tinder for goats, whatever it might be, then sure, I'm gonna put a few people in a room and go build this."

Perhaps Agile, or something like it, was inevitable: If software projects were going to be successful in the nimble, digital-first future, they needed to be able to, as goes the tech parlance, pivot-to respond to changes. The web profoundly changed the way software is delivered. Today's software isn't typically burned onto a CD-ROM and stocked on a store shelf; updates can be pushed to your laptop or smartphone remotely. This makes it easier to add features or fix bugs after releasing the product.

"In order to succeed in the new economy," Highsmith writes in his 2001 summary of the retreat, "to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the bejeebers (you can't use the word 'shit' in a professional paper) out of traditionalists."

But this isn't just a software story. Today, teams across industries and around the world are "going Agile"-or, at least, using bits and pieces of the Agile philosophy. The document itself has been translated into over 60 different languages.

Cockburn believes that's because what Agile "managed to decode was something about pure mental, team-based activities"-and that "it's just an accident of history that it was the programmers who decoded this."

Compared with "the more mainstream, more Waterfall-ish kind of ideas" that "lay out in great detail what everybody does," Agile is "much more empowering to the individuals doing the work," Fowler says. And, since it has been adopted by a spectrum of professions, Arie van Bennekum goes so far as to suggest changing the word "software" to "solutions," in order to open up Agile to everyone.

Despite discussions over whether the Manifesto itself should be amended, many of the original signers see the document as a historical-not a living-document. "It's like a Declaration of Independence in U.S. history," says Cockburn. "You don't go back and rewrite that."

"I think those four bullet points are still as valid as ever," says Grenning. "I don't expect them to change."

With the end of public signing, it seems unlikely that the Agile Manifesto will ever officially change, but that doesn't mean there aren't problems in the world of Agile. Over the course of our conversations, many of the framers expressed a frustration with modern Agile. On the heels of Agile the philosophy came Agile the industry: Agile software, Agile coaching, Agile trainings, and Agile conferences. There's no shortage of ways you can spend money to try and make your business or team "Agile."

But there's a particular irony here: Agile is a philosophy, not a set of business practices. The four bullets outline a way of thinking, a framework for prioritizing all the complicated parts of a project. They don't tell you what software to buy or how to hold your daily team meeting. "Now you can go to a conference, and there's aisle after aisle of people who are selling you computer tools to run your process. And they say it's Agile," says Cunningham. He points to the first value of the Agile Manifesto. "It says, 'Individuals and interactions over processes and tools.' How did [Agile] become a process-and-tools business?"

Cunningham thinks that "other people saw dollar signs and wanted to do the dollarsign thing." He adds, "Money has been made."

Van Bennekum, who is today a thought leader at Wemanity, says, "I see people being an Agile coach absolutely not knowing what they're talking about," which is "upsetting."

Meanwhile, Jon Kern, the chief architect at Fire Planning Associates, admits he "kind of stepped out of the Agile ring"-exhausted after a lot of people just didn't get it. "You get a lot of people, just snake-oil salesmen-folks that say they're doing Agile when it's Agile in name only," he says. Kern compares Agile to yoga, arguing his practice is personal and that he doesn't "try to tell other people how to practice."

The monetization of Agile aside, the influx of nontechnical users has created some conflict. Martin maintains that the "most annoying aspect right now" is that Agile "has been taken over by the project-management people," leaving "the technical people and the technical ideas" behind.

Jeff Sutherland, a cocreator of Scrum and the CEO of Scrum, Inc., is frustrated by misreadings of the document within the software community itself. Sutherland says he sees teams in Silicon Valley that claim to be Agile, but are "not delivering working product at the end of a short iteration." This, he says, puts them "in violation of the second value" of the Manifesto. "This kind of thing that most people are doing that they can't get anything working in any reasonable time-that they claim is Agile because anybody can do whatever they want-is not consistent with the Agile Manifesto," he points out.

A few have gone so far as to proclaim that Agile is dead. But Cockburn argues that there's always some benefit to trying Agile, even if it's not perfect: "Even badly done, Agile outperforms all of the alternatives, or at least, the main older alternative [Waterfall], which is out there."

The intricacies-and passions-of these debates demonstrate just how big Agile has become. When I ask Kern what expectations he had leaving Snowbird all those years ago, he laughs. "For the 10th-[anniversary] reunion, we were trying to come up with some words to put on a T-shirt," he explains, "and my proposal was: 'Four measly bullets, and all this shit happened.'"

Scrum: A Breathtakingly Brief And Agile Introduction

Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products. The brainchild of a handful of software engineers working together in the late 20th Century, scrum has gained the most traction in the technology sector, but it is not inherently technical and you can easily adapt the tools and practices described in this book to other industries. You can use scrum to build a better mousetrap, for example, or to run the marketing division of a puppy chow company. You can even use it to collaborate on writing a book-we did.

A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in. One of the mantras of scrum is "inspect and adapt," and scrum teams are characterized by an intense focus on continuous improvement-of their process, but also of the product.
This tiny book is a just-the-facts-ma'am introduction to the various moving parts of scrum: the various roles, artifacts and events that occupy the sprint cycle.

Roles

Scrum recognizes only three distinct roles: product owner, scrum master, and team member

Product Owner

A development team represents a significant investment on the part of the business. There are salaries to pay, offices to rent, computers and software to buy and maintain and on and on. The product owner is responsible for maximizing the return the business gets on this investment (ROI).

One way that the product owner maximizes ROI is by directing the team toward the most valuable work, and away from less valuable work. That is, the product owner controls the order, sometimes called priority, of items in the team's backlog. In scrum, no-one but the product owner is authorized to ask the team to do work or to change the order of backlog items.

Another way that the product owner maximizes the value realized from the team's efforts is to make sure the team fully understands the requirements. If the team fully understands the requirements, then they will build the right thing, and not waste time building the wrong thing. The product owner is responsible for recording the requirements, often in the form of user stories (eg, "As a <role>, I want <a feature>, so that I can <accomplish something>") and adding them to the product backlog. Each of these users stories, when completed, will incrementally increase in the value of the product. For this reason, we often say that each time a user story is done we have a new product increment.

The product owner role in a nutshell

Scrum Master

The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team's deliverable is the product, a scrum master's deliverable is a high-performing, selforganizing team.

The scrum master is the team's good shepherd, its champion, guardian, facilitator, and scrum expert. The scrum master helps the team learn and apply scrum and related agile practices to the team's best advantage. The scrum master is constantly available to the team to help them remove any impediments or road-blocks that are keeping them from doing their work. The scrum master is not-we repeat, not-the team's boss. This is a peer position on the team, set apart by knowledge and responsibilities not rank.

The scrum master role in a nutshell:

Developers (Development Team)

High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. The theory is that the people who do the work are the highest authorities on how best to do it. Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.

A scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team's success. However, on a scrum team, each team member's role is not to simply contribute in their special area. The role of each and every team member is to help the team deliver potentially shippable product in each sprint. Often, the best way for a team member to do this is by contributing work in their area of specialty. Other times, however, the team will need them to work outside their area of specialty in order to best move backlog items (aka user stories) from "in progress" to "done." What we are describing is a mindset change from "doing my job" to "doing the job." It is also a change in focus from "what we are doing" (work) to what is getting done (results).

The developer (development team) role in a nutshell:

So, how many team members should a scrum team have? The common rule of thumb is seven, plus or minus two. That is, from five to nine. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.

Scrum Artifacts

These are the tools we scrum practitioners use to make our process visible.

The Product Backlog

The product backlog is the cumulative list of desired deliverables for the product. This includes features, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce. Generically, they are all referred to as "backlog items." While backlog item is technically correct, many scrum teams prefer the term "user story," as it reminds us that we build products to satisfy our users' needs.

The list of user stories is ordered such that the most important story, the one that the team should do next, is at the top of the list. Right below it is the story that the team should do second, and so on. Since stories near the top of the product backlog will be worked on soon, they should be small and well understood by the whole team. Stories further down in the list can be larger and less well understood, as it will be some time before the team works on them.

Each item, or story, in the product backlog should include the following information:

The Sprint Backlog

The sprint backlog is the team's to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.

Burn Charts

Pasted image 20260301130258.png|400

A burn chart shows us the relationship between time and scope. Time is on the horizontal X -axis and scope is on the vertical Y-axis. A burn up chart shows us how much scope the team has got done over a period of time. Each time something new is completed the line on the chart moves up. A burn down chart shows us what is left to do. In general, we expect the work remaining to go down over time as the team gets things done. Sometimes the work remaining changes suddenly, when scope is added or removed. These events appear as vertical lines on the burn down chart: a vertical line up when we add new work, or down when we remove some work from the plan.

Task Board

When the team's tasks are visible to everyone from across the room, you never have to worry that some important piece of work will be forgotten.
The simplest task board consists of three columns: to do, doing and done. Tasks move across the board, providing visibility regarding which tasks are done, which are in progress, and which are yet to be started. This visibility helps the team inspect their current situation and adapt as needed. The board also helps stakeholders see the progress that the team is making.

Definition Of Done

Done is a wonderful word; when the team gets a user story done it's time to celebrate! But sometimes there is confusion about exactly what that word "done" means. A programmer might call something done when the code has been written. The tester might think that done means that all of the tests have passed. The operations person might think that done means it's been loaded onto the production servers. A business person may think that done means we can now sell it to customers, and it's ready for them to use. This confusion about what "done" means can cause plenty of confusion and trouble, when the salesperson asks why the team is still working on the same story that the programmer said was done two weeks ago!

In order to avoid confusion, good scrum teams create their own definition of the word "done" when it is applied to a user story. They decide together what things will be complete before the team declares a story to be done. The team's definition may include things like: code written, code reviewed, unit tests passing, regression tests passing, documentation written, product owner sign-off, and so on. This list of things that the team agrees to always do before declaring a story done becomes the teams "definition of done." The team will likely print out their definition of done as a checklist, and post it next to their task board. When the team thinks a story is done, they all gather around and review each item, to confirm that it has been completed. Only then will the team declare the story as done.

The Sprint

Pasted image 20260301130639.png|475

The sprint is the foundational rhythm of the scrum process. Whether you call your development period a sprint, a cycle, or an iteration, you are talking about exactly the same thing: a fixed period of time within which you bite off small bits of your project and finish them before returning to bite off a few more. At the end of your sprint, you will be demonstrating working software or thy name is Mud.

The more frequently the team delivers a potentially shippable product increment, the greater freedom the business has in deciding when and what to ship. Notice that there are 2 separate decisions here:

  1. Is the product potentially shippable? That is to say, is the quality high enough that the business could ship it? Are all of the current stories done? This is a decision for the team.
  2. Does it make business sense to ship what we have at this time? Is there enough incremental value present to take the current product to market? This is a decision for the business.

Additionally, the more frequently the team delivers and demonstrates a potentially shippable product increment, the more frequently the team gets feedback, which fuels the important inspect-and-adapt cycle. The shorter the sprint cycle, the more frequently the team is delivering value to the business.

As of this writing, it is common for scrum teams to work in sprints that last two weeks, and many teams are starting to work in one-week sprints. Much of the original writing about scrum assumed a month-long sprint, and at the time that seemed very short indeed!

The table below maps out the various meetings you would schedule during a one-week sprint. You don't have to call them meetings if you're allergic to the term or consider meetings to be a form of repetitive stress injury; you can call them ceremonies, as many scrum adherents do. The meeting lengths shown are an appropriate starting point for a team doing one-week sprints.

Pasted image 20260301130903.png|400

Sprint Planning

Sprint planning marks the beginning of the sprint. Commonly, this meeting has two parts. The goal of the first part is for the team to commit to a set of deliverables for the sprint. During the second part of the meeting, the team identifies the tasks that must be completed in order to deliver the agreed upon user stories. We recommend one to two hours of sprint planning per week of development.

Part One: "What will we do?"

The goal of part one of the sprint planning meeting is to emerge with a set of "committed" stories that the whole team believes they can deliver by the end of the sprint. The product owner leads this part of the meeting.

One by one, in priority order, the product owner presents the stories he would like the team to complete during this sprint. As each story is presented, the team members discuss it with the product owner and review acceptance criteria to make sure they have a common understanding of what is expected. Then the team members decide if they can commit to delivering that story by the end of the sprint. This process repeats for each story, until the team feels that they can't commit to any more work. Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.

Part 2: "How will we do it?"

In phase two of the sprint planning meeting, the team rolls up its sleeves and begins to decompose the selected stories into tasks. Remember that stories are deliverables: things that stakeholders, users, and customers want. In order to deliver a story, team members will have to complete tasks. Task are things like: get additional input from users; design a new screen; add new columns to the database; do black-box testing of the new feature; write help text; get the menu items translated for our target locales; run the release scripts.

The product owner should be available during this half of the meeting to answer questions. The team may also need to adjust the list of stories it is committing to, as during the process of identifying tasks the team members may realize that they have signed up for too many or too few stories.

The output of the sprint planning meeting is the sprint backlog, the list 3of all the committed stories, with their associated tasks. The product owner agrees not to ask for additional stories during the sprint, unless the team specifically asks for more. The product owner also commits to being available to answer questions about the stories, negotiate their scope, and provide product guidance until the stories are acceptable and can be considered done.

Daily Scrum

The daily scrum, sometimes called the stand-up meeting, is:

Daily. Most teams choose to hold this meeting at the start of their work day. You can adapt this to suit your team's preferences.

Brief. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell. The daily scrum should always be held to no more than 15 minutes.

The daily scrum, sometimes called the stand-up meeting, is:

Daily. Most teams choose to hold this meeting at the start of their work day. You can adapt this to suit your team's preferences.

Brief. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell. The daily scrum should always be held to no more than 15 minutes.

Pointed. Each participant quickly shares:

  1. Which tasks I've completed since the last daily scrum.
  2. Which tasks I expect to complete by the next daily scrum.
  3. Any obstacles are slowing me down.

The goal of this meeting is to inspect and adapt the work the team members are doing, in order to successfully complete the stories that the team has committed to deliver. The inspection happens in the meeting; the adaptation may happen after the meeting. This means that the team needn't solve problems in the meeting: simply surfacing the issues and deciding which team members will address them is usually sufficient. Remember, this meeting is brief!

Story Time - Product Backlog Refinement

In this meeting you will be discussing and improving the stories in your product backlog, which contains all the stories for future sprints. Note that these are not the stories in the current sprint-those stories are now in the sprint backlog. We recommend one hour per week, every week, regardless of the length of your sprint. In this meeting, the team works with the product owner on:

Acceptance Criteria

Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know when then the story is implemented as intended. Some people like to think of them as acceptance examples: the examples that the team will demonstrate to show that the story is done.

Story Sizing (Estimation)

During story time, the team will assign a size (estimate, if you prefer that term) to stories that haven't yet been sized. This is the team's guess at how much work will be required to get the story completely done.

Story Splitting

Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand, and easier for the team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list. While the product owner may do much of this work on their own, story time is their chance to get help from the whole team.

As of this writing, the story time meeting isn't an 'official' scrum meeting. We suspect it will be in the future, as all of the high performing scrum teams we know use the story time meeting to help keep their product backlog groomed.

Sprint Review

This is the public end of the sprint; invite any and all stakeholders to this meeting. It's the team's chance to show off its accomplishments, the stories that have met the team's definition of done. This is also the stakeholders' opportunity to see how the product has been incrementally improved over the course of the sprint.

If there are stories that the team committed to but did not complete, this is the time to share that information with the stakeholders. Then comes the main event of this meeting: demonstrating the stories that did get done. Undoubtedly the stakeholders will have feedback and ideas, and the product owner and the team members will gather this feedback, which will help the team to inspect-and-adapt the product.

This meeting is not a decision-making meeting. It's not when we decide if the stories are done; that must happen before this meeting. It's not when we make decisions or commitments about what the team will do during the next sprint; that happens in sprint planning.

How long should the sprint review be? We recommend scheduling one-half to one hour for every week of development. That is, if you have a one-week sprint, then this meeting might be 30−60 minutes. If you have a twoweek sprint, then this meeting might need one to two hours. After you have done it a few times, you will know how long your team needs-inspect and adapt!

Retrospective

While the sprint review is the public end of the sprint, the team has one more meeting: the retrospective. Scrum is designed to help teams continuously inspect and adapt, resulting in ever-improving performance and happiness. The retrospective, held at the very end of each and every sprint, is dedicated time for the team to focus on what was learned during the sprint, and how that learning can be applied to make some improvement. We recommend one to two hours of retrospective time for each week of development.

Unlike the traditional "post mortem," the aim of a retrospective is never to generate a long laundry list of things that went well and things that went wrong, but to identify no more than one or two strategic changes to make in the next sprint. It's about process improvement.

Abnormal Sprint Termination: When Good Sprints Go Bad

In scrum, the basic agreement between management and the team is that management won't change up requirements during a sprint. Still, every once in a while something happens that invalidates everything in the sprint plan-a business is sold, a game-changing technology enters the market, a competitor makes a move. The decision to terminate the sprint early is fundamentally a business decision, so the product owner gets to make the call on an "abnormal sprint termination." Despite the name, neither Arnold Schwarzenegger nor James Cameron need get involved.

If the product owner does decide to terminate the sprint early, the team will back out any changes that they have made during the sprint to avoid the problems that come from half-done work. Holding a retrospective is especially important after a sprint is abnormally terminated, as it helps the team learn from the experience.

Inspect & Adapt, Baby

So, why do we do development work in these short cycles? To learn. Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback-from customers, from the team, from the market-and to learn from it. What you learn while doing the work in one cycle informs your planning for the next cycle. In scrum, we call this "inspect and adapt"; you might call it "continuous improvement"; either way, it's a beautiful thing.