People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me. People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.
Two Teams Separated by a Common Process
George Bernard Shaw was an Irish author in London who memorably said “England and America are two countries separated by a common language.” The same can be said about teams developing in agile and waterfall processes.
The story of agile adoption is one that has many colorful examples of adoption and of spreading the gospel. Some practitioners traveled across the ocean from the agile continent to the lands of agile and opportunity to reap the rewards. A few of those, after realizing the benefits of agile, invade our consciousness with a hellfire and brimstone tale of doom for anyone who doesn’t convert to the new religion.
Others seem hell-bent on kidnapping entire development teams, smuggling them across the ocean in the belly of steamer ships and unceremoniously dumping them in the land of agile, ready or not. Scrum is but one branch of the agile movement.
Stalwarts of the old way, which has worked fine for me, thank you very much, refuse to leave their comfortable lives to step into the unknown wilds of agile. Open-minded but responsible potential converts ask questions to gain an understanding of what life in the new world might be like. What will life be like if I join this Scrum congregation?
How Does Scrum Really Work?
The best explanations of how scrum works that I’ve read come from Mike Cohn and Mountain Goat Software. The training, videos, and explanations they share provide fantastic top-down introductions (as well as guidance after adopting Scrum). His book, User Stories Applied, is the ultimate reference when gaining an understanding of the mechanics of using user stories as the central artifacts for developing software with scrum.
[The process diagram above provides a good outside-in, top-down view of how “this newfangled process” results in shippable product, incrementally. It is a great way to present the concept of Scrum, and incremental development in general.
When people I’ve worked with first gain this understanding, they often ask, what are the artifacts that live in these backlogs? User stories live there. Sometimes use cases make more sense than user stories for Scrum– it depends (read the article to see which works best in your circumstance). The common element is an outside-in, user-centric approach to describing which problems the software is intended to solve. This is also known as goal-driven development.
Once people understand the top-down view of the process, and have an idea of what user stories are, the next question they tend to ask is “how do stories move through the Scrum process?”
The first attempt at answering this question leans on the process diagram above:
- The product owner takes the most important stories from the product backlog and puts them into the sprint backlog – collaborating with the team to agree on the scope of work for this sprint (based on the amount of work, capacity of the team, real-world constraints, etc).
- The team “works the stories“, meeting every day to communicate effectively and provide progress updates – best visualized with a burndown chart. This chart says “we started with X work to do, and every day, we track how much of X remains to be done.”
- At the end of the sprint, the work is done, and the software (or an update to the software) is ready to deliver.
- Sometimes, multiple sprints happen between releases – launches of the updated software, because customers (and the rest of your organization) incur a cost when changing to the latest version. But the output of each sprint is deliverable – that’s a key concept – even if you choose not to deliver it just yet.
What Does it Mean to Work The Stories?
I’ve repeatedly had people ask, after absorbing the above explanation, “what does it mean to work the stories?”
I’ve had consistent success (in bridging the language divide) using the following diagrams (drawn on a whiteboard) to explain how stories flow through the sprint process in Scrum.
The first diagram shows that user stories have a structure – the story itself, and the acceptance criteria for the story. I also establish that the story is going to go through a life cycle within the sprint.
[Next I remind folks that the user stories make it into the sprint backlog because they are the most important (highest priority) not-yet-implemented stories in the product backlog.
[Developers on the team pull stories from the sprint backlog and begin working on them. These stories are work in progress, and are owned by individuals. Some teams maintain that priority order within the sprint backlog (e.g. implement the most important story in the sprint first, etc.), while other teams use a more coarse-grained approach, relying on the product backlog prioritization to assure that everything in this sprint is the next most important stuff, and the order that the team implements, within the sprint, is up to the team. Some folks like to strenuously debate this decision (don’t prioritize within sprints vs. do prioritize within sprints). Both approaches are valid, and you should choose the right one for your team.
[As each user story owner believes that her work is complete (all unit tests pass, and the developer believes that the acceptance criteria have been met), the story is ready to be tested by QA. This step, in particular, helps people who are new to scrum and who think of things as “code and test”, to make some sense of the inner workings of a sprint. When working with a team that was under-staffed in the QA department, I discovered that calling out this queue of user stories waiting to be tested helped convince management to increase QA investment in the team. When too many stories pile up here, you know you have a problem.
[The scrum team member responsible for testing the user story has the responsibility of assuring that it meets all of the acceptance criteria. He pulls the story from the queue of “done” stories, and tests.
[If the story fails to meet any of the acceptance criteria, it moves back into either the sprint backlog or the being developed column, where a member of the team resumes ownership of the user story and works to resolve the issue. Once the issue is resolved, the user story is re-queued for testing. When the user story meets the acceptance criteria, it is moved into the done done column.
[Conclusion
If you are new to Scrum, and wondered how the sausage is made inside a sprint, this gives you a framework for understanding what is going on, and how the team delivers. If you already know or use Scrum, you may have learned a couple things.
- Using this framework to describe how a sprint works is effective when explaining to people who do not have any experience with agile.
- Laying things out this way visually, will give you an easy-to-see signal if your team is unbalanced between developers and testers.
I’ve been involved with agile teams and processes for just over 11 years now, and incremental development is burned into my brain. If you are new to scrum, please let me know if this seemed like a good way for you to consume this material. If you’re an old hat, and have other suggestions or presentations, please add them in the comments below, because future readers will benefit from the additional ideas.
26 thoughts on “Foundation Series: Inside A Scrum Sprint”