On Scrum: a series on how we Scrum
In addition to developing big websites, we at Four Kitchens pride ourselves on our project management and using the Scrum process. Since we work primarily on client projects, our experience with Scrum is in many ways unique and different from “textbook” Scrum.
For example, we often have clients acting as Product Owner and have to externally manage client stakeholders, as well. Also, due to the size of our projects, we often have teams of 2 to 4 working on a project rather than the Scrum prescribed 5 to 7. Because of our unique experience with Scrum, we think it would be helpful to share our experience, our successes, and our failures in a series of posts. We are constantly applying Scrum to Scrum at Four Kitchens: reflecting on our process and trying to improve our approach to become better. These are just some of our lessons learned.
Let us know if there are any subjects you’d like to read about in this series. We assume a basic understanding of what scrum is when reading this series.
Adding “How to Demo” to user stories
Today’s lesson-learned is one we’ve had to learn many times over. Each Sprint, we get better at writing stories as thin, vertical slices. Sometimes we have the occasional misplaced developer story, but those are becoming rarer. We are also constantly improving at expressing the business value of the functionality within the story. We even write better descriptions and notes so that we don’t forget what we’ve already discussed in planning meetings and email threads. But one thing that we have found to be incredibly valuable, but often leave out, is to write a short “How to Demo” script for each story.
What we’ve found effective, is to write the steps for “how to demo” during the sprint planning. This earns us several things up front:
- Everyone is forced to agree what the story is about and understand it (and resize if necessary)
- It forces the product owner/client to commit to how the story will be demoed during the public demo.
- It ensures that the product owner/client has thought of the whole scope of the story and won’t bring up other pieces later in the sprint.
- The code/story/peer reviewer gets a script to test against.
- We save time when writing demo script: you just have to copy/paste from the story description.
If it’s so important, why are we ever skipping this step? Here are two primary reasons:
- Being consistent about having a ready, groomed, and prioritized backlog can be difficult, especially when the Client Product Owner has other obligations and duties within their own organization. The task of reviewing what each story (backlog grooming) is often left until the Sprint Planning Meeting. This leads to the next reason:
- In the interest of “just getting done with it” in the Planning Meeting, we will often just do our best to size stories with minimal discussion. We can power through the planning meeting, sure, but does that really help us in the sprint? Probably not. The goal of planning is to be 100% ready to do the work the team commits to in the sprint. While everyone may have their own understanding of what the Product Owner wants, they may not really know what they are going to have to show in the demo.
When we write a “How to Demo” script for every story in the sprint, we always find that the benefits outweigh the cost. If you haven’t done it, I encourage you to give it a shot. If you’ve given it a try, what has your experience been? Let us know in the comments.