First, make a list of required activities or features.
Write down some things, then put each of them on a post-it note and stick them on a wall.
Order those post-its. The most important go first.
- Post-its that have to get done first.
- The most valuable post-its.
Add/subtract/change post-its whenever. You now have a Product Backlog. Focus on now, but if you want to make big things later, make them vague. You'll split them into smaller tasks when you need to. Don't commit before you must. The Backlog is a list of options, not promises.
Rank the top post-its by difficulty. I prefer Fibonacci numbers: 1,2,3,5,8,13 etc. This is called Sprint Planning.
- Take a post-it you know will take about a day to complete and mark it a 5.
- Then compare all the other tasks to that one. Are they less time-consuming? Mark them a 3. More? 8. Same? 5.
- If the task is more than 13, you should break it into smaller chunks.
Take the top 25 points or so and post them in a new category, your Sprint Goal. These are things you will complete within a time-box called a Sprint
- take your pick: 5 days, 10, 20, whatever.
- 10 days is standard. Don't do more than 20.
- IMPORTANT! Do not change the time-box unless it's clearly not right for you! The power of scrum is rhythm, like the rhythm of a rowing team.
- Do not start a new sprint early because you completed the goal. Add more post-its instead.
- Do not cancel a sprint without very very very good reason!
- The goal does not change so the team can focus and commit to delivery. Goals only change sprint-to-sprint.
Each day, the team has a short Daily Scrum. This is a chance for the team to self-organize. The team inspects the goal and coordinates their work. This allows them to take ownership and commit. 3 questions are asked:
- What did we do yesterday to accomplish the goal?
- What will we do today to accomplish the goal?
- Are there any blockers to accomplishing the goal?
At the end, the goal is presented in a Sprint Review. The team presents so that they can take ownership and get direct feedback to learn what is valuable to the stakeholders. Only completed work is presented.
The team also inspects their work flow in a Sprint Retrospective to identify what needs improvement. Actions are taken to improve performance. They may change how many points they take each sprint or how communication happens between them, for example.
Repeat steps 2 through 8 until there are no more post-its.
There are three roles in a scrum team:
The Team: The people responsible for committing to and delivering the Sprint Goal. They self-organize and need little supervision.
The Product Owner: The one person who represents the stakeholders. It's her job to prioritize the backlog, and communicate the stakeholders needs to the team. She can also be part of The Team.
The ScrumMaster: The person responsible for facilitating scrum, and removing blockers that are outside the team's scope of authority. Otherwise, she shepherds the team toward finding solutions for themselves. The ScrumMaster can also be part of The Team, but conflicts of interest mean she cannot also be the Product Owner.
Groups larger than 12 don't self-organize well. In that case you'd have multiple teams.
Questions? Concerns? That's natural! Scrum requires letting go of a Command and Control mindset, so ask questions! Raise objections! But most of all, try it out and see for yourself!