Sprint Retrospective
If the Sprint Review is for inspecting the product increment, the Sprint Retrospective is for inspecting the team processes. Here, the team discusses what went well, what went wrong, and what can be improved. Task management can be a common theme, and there are many creative ways to make a Sprint Retrospective bring out process improvements. As the Scrum Master, you can set up the context and prime directive for this ceremony in such a way that the team can ideate on how they can be better or be more confident with task ownership. Have the team analyze their inputs and come up with the action items for them to commit to.
The Daily Standup
A quick 15-minute meeting, the Daily Standup is where each team member discusses what they’ve finished so far, what they commit to doing for the day, and what help they need or what problems they’re having. This is not a problem-solving meeting; rather, this is simply for team members to hear each other on where they are in the Sprint.
Product Backlog Prioritisation
Product Backlog Prioritisation is similar to a Sprint Planning, except the team is planning for future Sprints and releases. Here, the Product Owner and the development team talk through PBIs that have not yet been discussed. The desired functionality is made clear, acceptance criteria are declared, and efforts for completing the PBIs in terms of time and/or complexity are estimated. It would be better if tasks for the PBIs are also identified during this session. Holding regular Product Backlog refinement sessions is a practice that can save the team time during Sprint Planning, and can give everyone a better idea of where the project will be heading to next.
On Estimating and Commitment
Scrum is a largely empirical process that practices transparency, inspection, and adaptation with Scrum artifacts and through Sprint ceremonies.
On Estimating and Commitment
Scrum is a largely empirical process that practices transparency, inspection, and adaptation with Scrum artifacts and through Sprint ceremonies. In order to improve continuously and move forward, there should be a basis for the team to act on, and this is where the metrics come in handy. The most common way to track how the team progresses would be using a burn-down chart.
The burn-down chart is a graphical representation of the amount of work done versus the remaining work for each Sprint, using the story points estimated during Spring Planning. More than seeing progress, it’s a great tool to learn how much work the team can commit to in a Sprint. It’s normal for teams to overcommit work at the start of the project, but over time, estimates will improve, and so will the amount of work the team will commit to finishing in a Sprint.
Coaching the Scrum Team
The Scrum Master plays the difficult part of ensuring that tasks are done without team members assigning tasks to others. The Scrum Master is also in no position to be the one assigning tasks. Instead, the Scrum Master should find ways to encourage the team to trust themselves and each other to be able to pick and own their tasks. Instead of team members telling others what to do, have them ask for help. To address the problem of no one owning a task, the Scrum Master should find out why no one wants to do it. Then they can give the power back to the team and ask them, “How do we solve this problem?” or “What’s the best way to go about this?”
The main job of the Scrum Master is to have the team use the Scrum practices in the work that they do. They are there to remove impediments and protect the team from anything that threatens their productivity. The Scrum Framework itself already provides the venue for the team to be self-organizing, and the Scrum Master only needs to coach the team to follow it.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: