Sprint and reflect
I have been focusing on scrum mastering throughout my masters program at the Centre for Digital Media. This post is an attempt to describe my process and my takeaways/learnings.
1. Sprint planning: the team starts by writing down a list of objectives for the coming sprint. The Product Owner and Scrum Master then 'translate' these objectives into user stories and hand them over to the dev team. The dev team breaks down the user stories into tasks and put them in 'To Do'. Figure 1 shows a series of user stories in the backlog and their respective tasks on post-its.
Takeaways: 1) the whole team feels ownership over the product as everyone helps defining the sprint objectives, 2) everyone thinks about the sprint goals first, 3) the dev team has total control over production.
2. Daily stand-up / Scrum: the team meets every day at the same time and each team member answers the following questions: 1) What did I do yesterday? 2) What am I doing today? 3) What do I need help with?
Takeaways: the whole team gains clarity on dependencies and priorities. The managers have more visibility on "To do" and "In progress" items.
3. Demos # Daily: the purpose of daily demos is to inform the team of outstanding dependencies and increase everyone's sense of ownership over the product. # Weekly: once a week the team shows the latest prototype(s) to the project stakeholders (Fig 2.) and shares insights of the week's user tests. Client feedback is gathered and organised and provides the team with ideas on how to improve and what to prioritize for the next sprint.
4. Sprint review: Did the team deliver? What is left in progress? Do the user stories and goals still make sense for next sprint? Those are questions that I usually ask the dev team to close the sprint and prepare for the new one.
5. Sprint retrospective: # Project retro: after the review, the team reflects on the project by writing a series of "plus" and "deltas" regarding the product/project (Fig 3.) during 2 min. # Process retro: following the project retro, the team reflects on the process and writes a series of "plus" and "deltas" (Fig 4.) during 2 min. The process retro is always very helpful and helps the team identify problems regarding the working environment: process, team members... # Actionables: the Scrum master then asks the dev team and the PO how the post-its should be regrouped and if any clusters can be made. The team then agrees on the topics that should be addressed in order to improve the process and begin the lean Coffee. The objectives should be Specific, Measurable, Attainable, Relevant and Time-specific (SMART).
My takeaways: 1) a process should be adjusted and refined every week, 2) sprints should be planned and reviewed differently in discovery and production, 3) the scrum master doesn't have all the answers, the dev team does.
Here's another post you might find interesting: "Understanding the problem space" (workshop facilitation).