- Pick a product owner.
He or she must have the domain knowledge and decides what need to be done and why while taking risks and rewards into account).
- Pick a team.
Scrum team must have the skills to bring product owner’s vision to reality. How to make it happen is up to the team. Keep the team size small, 3 to 9 people is the rule of thumb).
- Pick a Scrum Master.
He or she is to coach Scrum team and help eliminate anything that’s slowing them down).
- Create and prioritize product backlog.
Backlog is a list of high-level tasks that can be evolved over the life time of the product; product owner is required to prioritize decisions across the backlog).
- Refine and estimate product backlog.
Scrum team who’s going to complete the items in the backlog see if it’s doable and how much effort it will take. IS there a definition of done, that is, everyone agrees on what standards must be met to call something ‘done’? Estimate in relative size (S, M, L, XL) a rather than in absolute hours. Or estimate in point value 1,2,3,5,8,13…).
- Sprint planning.
This is the first of the Scrum meetings. The team, the Scrum master and the Product Owner sits together to look at the top of the Backlog and forecast how much of it they can complete in this Sprint (usually sprints are less than a month). If the team has been going for a few sprints, they should take in number of points they did in the last Sprint. That number is known as the team’s Velocity.
- Make work visible.
Make a Scrum Board with 3 columns: To Do, Doing, Done. Move items across the board as they’re completed, one by one.
- Daily stand-up aka daily scrum.
Take no more than 15 minutes each day to discuss (1) things you did yesterday to help team finish the Sprint (2) things you do today to help the team finish the Sprint (3) obstacles blocking the team from achieving Sprint goal.
- Sprint review aka sprint demo.
Team shows what they have accomplished during the sprint. Anyone is invited from product owner to management customers. The team demonstrates what they were able to move to Done during the sprint. The demo may not be a completed product, but it should be a completed feature of one.).
- Sprint retrospective.
Team sits together to think about what went right, what could have gone better and what can be made better in the next Sprint. What is the improvement ‘kaizen’ that the team can implement right away? To be effective, sprint retrospective
requires emotional maturity, not blaming but looking at things objectively and being open to feedback.
- Immediately start the next Sprint.
Take the team’s experience with impediments and process improvements into account and start the next Sprint.