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.
The Second Standup
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:
The Rest of the Sprint
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.
Note: Using a Third Engineer for Code Review
Since many of the tasks in this story are worked on by pairs, a third engineer has to be involved in doing the code review. Not every team requires code done by pairs to be reviewed by a third engineer, but this team has included that as part of their definition of done.
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.
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.
