The next morning, the team has the first standup of the new sprint. As usual, the team goes around the circle, with each engineer reporting on what they've done since the last standup, what they're planning to do until the next standup, and whether they have any blockers. The first three engineers still have cleanup work to do from stories they've failed to finish in the previous sprint, and they have no blockers. But the fourth engineer, the most junior on the team, doesn't have any work left to do, and is available to take on a new story.

"Looks like I get to take the big one," the junior engineer says nervously. There's some humorous cheering from the rest of the team.

"OK, we're putting your name on it," the scrum master says.

"I guess I'll start tasking it out," the junior engineer says, "but I'm gonna need some help. Does somebody want to pair with me?"

"Sure, we can work together," the next engineer says.

"Great," the scrum master says. "So you two are a team, and you're working on this story. Got any blockers yet?"

"Just the usual sense of intimidation," the junior engineer says. "But I guess we've got this."

The first thing to do when taking on a big story is task it out. This means defining the individual subtasks that can be worked on in parallel, so that the story doesn't get trapped in one person's head. Some teams prefer to split stories into tasks during the planning meeting, but this team has decided that the person who takes ownership of the story will also be responsible for breaking out the tasks.

Depending on the preferences of the team, tasks can be written just like stories, or they can be written as technical specifications more appropriate for sharing ideas among engineers. Tasks can also be entered into a number of scrum board tracking systems, so they can be tracked and assigned to different people as they go through development, review, and QA.

The pair of engineers responsible for the puppy story works through the sub elements that will be necessary to make the story a reality. It takes several hours, and they have to call in the product owner a couple of times to clarify points. By the time they're done, they've broken out more than six tasks, each of which will need to be done before the story can go to QA for final testing.

Together, they write up the descriptions of the tasks and add them to the electronic scrum board the team shares. Another advantage of having the tasks available on the board is that team members who aren't directly responsible for the whole story can still take responsibility for a task, so the work can get done more efficiently. This also had the advantage of spreading the knowledge about how the story is implemented around the team.

When they are done adding the new tasks to the scrum board, it looks something like this:

The engineer who's taken ownership of the story makes a point of alerting QA about the state of the tasks. After talking with QA, they discuss the testing plan, and decide on some standards for how the tests should be evaluated to match the acceptance criteria of the original story. In this case, it is agreed that QA will be involved in testing the pieces of the story while all of the components are being completed. Getting QA involved ahead of time gives them a chance to start writing the tests early.

Once all the tasks have been defined, the initial pair determines the priority order of the tasks, and decides which task they think needs to be done first in order to support the development of the rest of the tasks. Between them, they feel that they have the skills necessary for the first task, so they assign themselves to that task, and set to work developing the necessary code without calling in additional help.

At this point, they move the first task for the puppy story to the in progress column:

A little later, one of the other engineers on the team completes a story, goes over it with QA to make sure it's complete, and is then free to start working on new stories. The engineer checks the board, and sees that several of the new tasks from this high-priority story have not yet been started. After checking in with the first pair to make sure there won't be any overlap between the tasks, the engineer takes ownership of the next highest priority task in the top story, updates the scrum board, and gets to work.

Once the second task is in progress, the scrum board looks something like this:

The product owner is following up as well, doing some work on the copy for the puppy story, and checking in with Design on the status of the assets. Now it's a good time to check the scrum board to see what's going on.

One story that was in progress and not yet completed in the last print is now listed as ready to demo. The new story for creating the puppy version of the site is started, has been split out into six tasks, and two of those tasks are already in progress. The product owner makes a mental note to check up on the status of the tasks after the standup tomorrow.

Before the end of the day, the scrum master checks on the status of the stories on the board. The new tasks have been added, and the format is clean, which means the team working on the puppy story has followed existing conventions correctly. There doesn't seem to be any need to interrupt the engineers who are working on their stories.

The next day at the daily standup, the QA engineer responsible for the puppy site story attends, and makes note of the status of all of the tasks. The product owner attends as well.

The first to report is the junior engineer responsible for the puppy story, who explains how they have broken the story into tasks, and how they have begun working on the first task.

"We'd appreciate any feedback on the task breakdown," the junior engineer says. "I think we addressed all of the acceptance criteria, but the more eyes we have on this the better I'll feel."

"So you'll be working on this task for the rest of the day?" the scrum master asks.

"Yeah, I think we will."

"Any blockers?" the scrum master asks.

"I don't think so," the junior engineer replies.

"No, I don't think we have any blockers," the other engineer on the story agrees. "We should be working on this at least until tomorrow."

"Great," the scrum master says, making a note to follow up on the request for feedback, and then continues around the circle until everybody has reported. Then the team is dismissed, and the engineers go back to their various projects.

After the standup, the product owner checks in with the scrum master and the people working on the tasks for the puppy story, and lets them know that the design work has been started, and the copy updates they discussed at the planning meeting are in the repository. None of the tasks that require design assets have been started yet. Based on the updates from the standup, they probably won't be started until the designer has everything ready.

On the second day of the sprint, the product owner and the QA engineer both attend standup again. All the engineers are present, and nobody has any blockers for the stories they're working on. As the scrum master is just about to dismiss the team, one of the engineers speaks up.

"I have a quick question about how this puppy story is going to work with the help pages on the site," the engineer says. "I was thinking about it last night, and it's going to be confusing for people in the beta if there's nothing on the help pages that explains what the beta is, and how to get back to the regular site."

"That's a good point," the product owner says. "Do you think that's something we can handle with the plans for the custom header?"

"I'm not sure," the engineer says. "The header's currently not structured to show up differently on help pages."

"Is that something you think would be easy to add?" the product owner asks.

"I wouldn't count on it," another engineer says. "The way the site is structured, the help pages are served separately from the rest of the content."

"That's right," the first engineer says. "It's going to be a tricky one."

"Do we need the whole team here for this," the scrum master asks, interrupting the conversation, "or can we take this offline?"

"I don't know," the product owner says.

"Yeah, we can take this offline," the first engineer replies.

"OK, great," the scrum master says. "In that case, the standup is over."

As the rest of the team steps back to their desks to continue working on their projects, the scrum master comes over to the product owner and the two engineers, who are talking about the help pages.

"Should the three of us discuss this now, or do we want to follow up on this later?" the scrum master asks.

"I think I see what the problem is," the product owner says. "I can write up a story that addresses the way I think it should work."

"Are we going to add that as a new story?" the scrum master asks.

"It feels like scope creep to me," the first engineer says.

"No, I think it's covered by the acceptance criteria for the original story," the product owner says. "These are pages on the site, and they need to be handled just like any other pages on the site."

"Let's check the acceptance criteria and make sure," the scrum master says.

Together, the four of them go over to a computer, pull up the scrum board, and take a look at the acceptance criteria for the story as the team has estimated it. In fact, the acceptance criteria do say that the changes in the header to support beta users of the puppy site need to accommodate all of the pages on the site, without distinguishing the help pages.

"Well, that's going to be a tricky one," the first engineer says.

"Do we need any further details about how it should be implemented once we have the updated text from the product owner?" the scrum master asks. "Or can one of you take on writing up the specifications and adding this task to the board?"

"I can do it," the first engineer says, a little glumly. "But it sure feels as if this might add more effort to the story than we expected."

"Yeah," the second engineer agrees. "I don't think we estimated this one with enough points."

"Well, we can't change the point estimate now," the scrum master says. "Just another data point. We'll have to do what we can."

"Does that mean you don't think you're going to be able to get this story done by the end of the sprint?" the product owner asks.

"We'll have to see," the first engineer replies.

The four of them stare at the story's acceptance criteria for a moment. Then the scrum master asks, "OK, are we all good? Don't forget to tell the story owner about the task you're adding."

They all nod and return to their jobs. After a few hours, the new task is added to the scrum board by the engineer who accepted that responsibility, and the board looks like this:

By the end of the sprint, most of the team has swarmed onto the puppy story, but not much else has gotten done. Design has finished the flow for the front-end user experience and the image assets, and works with the engineers to make sure they're integrated appropriately.

While the team is working on the code, QA is developing the tests necessary to validate it. QA also meets with the product owner a couple of times to clarify acceptance criteria. Eventually, each of the tasks moves across the board from In Progress to To Demo.

Despite the need to support the help pages, the team manages to finish and review all of the code to their satisfaction. Because of the unusual naming conventions they need to adopt in order to distinguish this code from the rest of the site, there is some confusion during code reviews. That slows down development a bit, but not enough to prevent the junior engineer who took ownership of the story from handing it off to QA for a final check before the end of the sprint.

The definition of done for this team includes both code review and QA, as well as client acceptance. Because QA has been integrated with the team from the start, they've been building the test suite throughout the sprint based on the acceptance criteria.

Most of the tasks for the story have produced reviewed code that can be unit tested independently as they're completed. Now it's a simple matter to run the integration tests and verify that the features work as expected from start to finish. If the story is accepted and pushed to production, these tests will be added to the universal suite for the site.

At the demo, everyone is in attendance, including the QA engineer and the designer who has worked on the puppy story. There's a lot of curiosity about how this is going to turn out. The scrum board shows all the stories that have been in progress for the sprint are ready to demo:

The first thing the product owner does is verify that the stories carried over from the previous sprint are now completed. After walking through those, and verifying that all of the acceptance criteria have been met, it's time to demonstrate the big story that has taken most of the time during the sprint.

"So, how do I get into the beta?" the product owner asks.

"You should have a sample invitation email with a link to join the beta," the junior engineer responsible for the story replies. "Check your inbox, and click the link to get started."

The product owner checks the email, and confirms that it matches the text that was provided. It looks very basic, but it does meet the acceptance criteria. The designer starts making notes.

Clicking the link in the email brings up a custom login page with the invitation message, which also meets the acceptance criteria. After clicking the accept button, the product owner logs in, and starts navigating around the puppy-friendly version of the site.

The top of the page shows the alert header, just as it was defined in the acceptance criteria for the story. "So far it looks pretty good," the product owner says.

"We had to take some liberties with the formatting in the header to accommodate the help integration," one of the engineers points out. "I don't think the solution is ideal, but it does get the job done."

"Yeah, let's check that out now," the product owner says. A few clicks, and the screen changes to show the help pages on the site. The header expands on these pages, revealing additional help topics for the beta that aren't covered in the standard help screens.

"That seemed to be the best way to get the information you needed up on the screen where people might expect to find it," the engineer says. "If we had had time to do the full refactor, we could have integrated it directly into the help topics, but there just wasn't time to do it with the code the way it was."

"That doesn't look great, but I see where you're coming from," the product owner says.

"I think we can come up with some more elegant ways to do that," the designer says from the back of the room. "I can work on some sketches."

"That would be good," the product owner says. "I really don't want to send it out looking like this."

"But it does meet the acceptance criteria, right?" the scrum master confirms.

"Yeah," the product owner agrees. "So if we do want to do updates for the visual design, that'll be a new story for the next sprint, right?"

"That's what it sounds like," the scrum master says.

After reviewing the rest of the features, and going through all of the acceptance criteria, the product owner identifies a number of areas where there's room for improvement. The team has made some expedient choices on visual layout in order to get all of the functionality in place.

Not all of the interface options were specified in the design comps, and some features were outside the scope of the existing style guide. The designer now takes notes, and confirms with the product owner that they'll go over these issues after the demo to discuss what needs to be worked on next.

But despite some visual lack of refinement, all of the boxes have been checked. For the sake of the scrum process, the team can consider the story completed, even if it isn't yet ready for production release. So the scrum master updates the story on the scrum board and sets the status to done. This updates the point count, adding all the points for the story to the total for that sprint.

By the end of sprint eleven, the team has completed all 24 points in the sprint backlog, and the scrum board looks like this:

After the demo is completed and the sprint is closed, the team sits down with the scrum master to go through the sprint retrospective. The point is to get people talking about what they think went well during the last sprint, what they could have done better, and what changes they think they should make to the process going forward.

"One thing I think went really well was having the opportunity to follow that big story from start to finish," the junior engineer who took responsibility for the puppy story says. "It gave me a great chance to see how our architecture works from top to bottom."

"You did a really good job on it," the engineer who had paired on that story says. "I learned some things about our own architecture that I didn't know, too. There's some really messy stuff in there."

"Yeah," another engineer says, "that's one of the things I think didn't go so well. I really think we should have had the chance to do the refactoring before trying to build this all out."

"I agree," the second engineer says. "But now at least we have a sense of where some of the mess is, so we know what to focus on first."

"It would have been easier if I had just been able to dive in and fix that stuff first," the third engineer says. "I already knew where most of it was, and it still bothers me that we did it backwards."

"At least now you're not the only one who knows," the second engineer points out.

"Yeah, but it sounds as if we're not going to get a chance to do the refactoring this sprint, either," the third engineer says, sounding grim.

"That's how it sounded to me too," a fourth engineer chimes in. "They're going to stick in the stories to get the design changes for the beta done first."

"We probably are going to have some design stories to fix the visuals for the beta," the scrum master says. "But the product owner did agree to give us time for the refactor as a top priority if we finished the story, and we did. I'll follow up on that before the planning meeting to make sure."

"Well one thing," the third engineer says, "is that I want to go through those new designs with a fine-toothed comb and make sure they're really final before we estimate them."

"Should we make that another goal for the next sprint?" the scrum master asks.

The engineers around the room nod. At the end of the retrospective, they came up with a short list of improvements they wanted to make to their process, as well as a couple of tasks for the scrum master to follow up on with the product owner.

The two points everybody can agree on are that working across the entire stack has been frustrating but also useful for exposing issues in the code that need to be fixed, and that the priority for the next sprint should be getting those issues addressed. One way or another, it's going to be an interesting planning meeting going into the next sprint.