Scrum: Working through a Story (Part 1)
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.
In the last chapter, we were introduced to the product owner’s world, and taken through the process of developing and creating a story for the team. We saw how requirements were gathered, how the product backlog was built up, and how the expectations of internal and external clients, along with other interested parties, translated into clearly defined scrum stories for the team.
Then we went through the process of seeing how stories are introduced to the team, and how the team estimated them. We watched as the team negotiated with the product owner to make sure that what they were going to work on made sense, and was capable of being finished within a sprint.
Now it’s time to follow that story through a sprint. In this chapter, we’re going to see how the team divides up a large story like the one we’ve been discussing into smaller tasks, and distributes these out so they can all be worked on and completed. We’re going to see how all aspects of the story get addressed until they meet the definition of done.
Finally, we’re going to see the team go through the demo process with the product owner, and with any luck, maybe the story will be accepted at the end of the sprint. Either way, there’s certainly going to be a lot to discuss at the retrospective. Let’s find out what happens.
Working Through a Story
By the time the planning meeting has ended, the team has committed to a new sprint backlog. As you may recall, the scrum board currently looks like this:
The new story for creating a test version of the site to support puppies, labeled 11-1, is high on the priority list, but it’s a little lower than some stories that are still in progress from the previous sprint, but haven’t been accepted yet. That’s a compromise the product owner is moving to make so that the team won’t lose momentum on stories that are almost completed.
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 First Standup
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.
Note: Attendance of QA in Standups
Some teams consider QA as core team members, but for the WithKittens team QA is not required to participate actively in all team activities. It’s entirely up to the people not directly on the team whether or not they will attend a standup. WithKittens QA attends standups only when alerted that new tasks or stories might be discussed. The product owner likes to be at all the standups when possible. Of course, neither QA nor the product owner speaks until after all the engineers on the team have reported on their status. Even then, the scrum master limits them to statements of relevance to the whole team.
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.