The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
Demonstrating the Story
A day before the demo, as part of the preparation, the product owner sits down with the junior engineer who owns the puppy story. They have already walked through the various components a number of times during the sprint, but the product owner wants to be sure all of the acceptance criteria can be demonstrated.
“Will we have this staged properly on production-ready servers in time for the demo?” the product owner asks.
“Pretty much,” the engineer replies. “That’s the server QA has been testing on. It should be fine for the demo.”
“Do I need to know anything special,” the product owner says, “or can I just go to the same server we’re using right now?”
“We shouldn’t need to set up anything custom,” the engineer replies. “I think you’ve been through the components a few times already. Once it’s deployed, you should be able to join the beta, test the features, and then exit the beta successfully.”
“Can I go through the whole thing right now?” the product owner asks.
“Not yet,” the engineer replies, “but QA has passed on everything, so we just need to go through deployment before tomorrow. It should be ready in time for the demo.”
“Great, I’m looking forward to seeing it,” the product owner says.
Checking Acceptance Criteria
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:
Note: What happened to the tasks?
All of the tasks that have been broken out for the puppy story are no longer relevant, and so have been hidden from view on the scrum board for the demo. Once a story has been completed, it isn’t relevant to the product owner what it took to get it done, only whether the entire story meets all the acceptance criteria. For the sake of the team, the individually defined tasks are still stored for later referenced if needed.
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:
Sprint Retrospective
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.
Summary
One of the things we’ve learned about scrum is that it can’t give you the team that you might wish to have, but it can help you optimize the resources that you have available, and support them in working together effectively. In this chapter, we’ve gone through how a team with some challenges approached a new story that stretched their resources.
- We saw how the team organized the work, and broke a big story out into engineering tasks so that it could be developed in parallel.
- We watched the team encounter issues with the acceptance criteria, and get feedback from the product owner about how to address them during the sprint.
- We saw the compromises that came up during the demo, and how they led to revised expectations for the upcoming sprint.
- And then we listened to the team go through their concerns at the retrospective, discussing what went well, what could have gone better, and what they hope to see in the next sprint.
Implicit in all of this is the philosophy of collaborative transparency and self-management behind scrum. In the next chapter, we’re going to discuss how to make scrum work for your team. We’ll talk about how to introduce the concept of scrum to an organization, what resources are needed to support scrum, and also how to address some of the anti-patterns that can show up when learning to apply scrum.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
