Earlier this year I worked with a team that was new to Agile, and to Scrum*. We spent a lot of time trying to understand the concepts and practices related to Scrum, but along the way we came up with questions we couldn't find answers for in the broader community of practice. So, we did what any group of analytically-minded people would do: we created our own Scrum Guide.
*Are you new to Scrum and want to learn more? Check out Mike Cohn's Article for a great introduction.
Here are some highlights:
How do I know when a user story is ready to bring into the Sprint Planning meeting?
Scrum does a good job of helping the team determine when a user story is done, but how do you know when something is ready to bring into the Sprint Planning meeting? There's no specific formula that will work for every story, but here are some questions you can ask yourself to help determine if your story is "ready enough":
- Can you readily identify the tasks necessary to implement the work?
- Can the user story be completed within half of the sprint?
- Can you describe how you will demonstrate the user story to the product owner?
How do I know which task to start working on?
In Scrum, tasks are not assigned. Each team member is responsible for pulling tasks to begin working, and team members are not distinguished by their roles. For a team that may be used to a traditional approach, this might not make sense. How do you know who starts on what, when tasks are not separated by role?
We found the following to be helpful:
Early in the project, have team members talk about their personal goals for their performance on the project, and discuss their strengths and areas they are comfortable contributing to with the team as a whole. To the extent possible, search for opportunities to allow team members to learn new skills without endangering project goals.
Knowing what each team member would like to work on, or would like to learn can help the group more easily parse out the work.
How do I know when to move a task from one column to the next on the board?
This question assumes you are using Kanban, or some tracking tool with a Kanban-esque approach. This seems like a pretty simple concept, but in practice it can actually be rather challenging. We came up with the following criteria to determine when to move a task from one column on the board to the next.
Tasks can be moved from "In Progress" to "QA" when the following criteria have been met:
- The scope of the work for the task has been implemented.
- All applicable Definition of Done criteria are met.
- At least two team members have reviewed the work and agree that the task is ready for QA.
Tasks can be moved from "QA" to "Complete" when the following criteria have been met:
- All applicable Acceptance Criteria are met
- All defects found have been fixed, or a plan to fix them has been created
- At least two team members have reviewed the work and agree the task is complete.
While your team may not have the same questions, I would offer at a minimum that the "two people agree" heuristic is a great way to find a solution when you do come across something that doesn't quite make sense to you, and isn't addressed by the body of knowledge available on Scrum.