This article is the continuation of The Daily Stand-up Checklist for ScrumMasters, part I. The aim of this series is to help Scrum Masters to prepare better for daily stand-up so it is efficient, productive and engaging. These tips are based on our observation of 100+ agile teams in their agile transformations.
In the first part, we covered the Room, Tools and Status sections. Let’s continue with the rest.
Finish First Principle
The fundamental principle of Agile is to focus on delivering working products. The reasons are very simple. Customers are satisfied, giving feedback early and often hence the product’s quality is much higher from the implementation and business perspective as well.
To achieve that we need to work according to priorities. To finish the top most important thing first as this is the most expected business value for the customer and his clients. The team should always pull work from the top of the Kanban board based on three simple principles:
- What I can to finish.
- What I know to finish.
- What I want to finish.
Sometimes a team member doesn’t know how to solve the problem, however, he wants to learn. This is highly appreciated in Agile. But based on priorities, not just anything I want to learn.
Before pulling any task card from the Kanban board it makes sense to ask yourself what can be finished today. As a Scrum team, we want to focus on finishing work to avoid disturbance and context switching which is the biggest pain of our life today. You wouldn’t believe it, but to get back to work from the interruption it costs some of us +50-80% of the duration of the interruption. At least based on statistics we get from our training where we play a game to find that number.
Such focus on delivering first has a huge impact on the success of the business as well. You can deliver stuff that is ready fast. You will be able to deliver new features nearly every day. Do you not need that? I think you are wrong. Maybe you do not need that for your business, not for your development. There are other teams, you need to integrate, you need to run tests often and early. You need to prepare deployment scripts with your DevOps teams. You need to provide early information to your support so they can learn to use new features. And what about work of marketing, preparation of blogs or screencast?
You should aim to deliver 100 times per day!
As Scrum Master, you will often notice some cards that got stuck in the Work In Progress column. The first indication will be a flat line on your burndown chart.
Check the progress of every task card on the Kanban board before the daily standup. Mark them down with some post-it strips so you can ask team members if they need help.
Before ScrumMaster asks team member if she needs a help, wait for a request for help.
If it doesn’t come, only ask then.
Does nobody offer help to the colleague who needs it? Ask team members who can help! IT guys are often introverts and ashamed to offer help as they often think it is “a break of law” to step into the code of colleague. Sometimes they are just shy to talk in front of the larger group.
Tip: If you ask, wait for the answer even if it is followed by dozens of seconds of silence. The answer will come, just wait patiently!
Any dependencies?
What does Scrum methodology say about dependencies? There should be no dependencies in the agile world (see INVEST principle), but it happens. Especially in the case of complex products, multiple agile teams participate in product development.
Dependencies should be identified during the release or sprint planning session and they should be marked on the user story card. Once the work is done, it is very welcome to inform other depending teams about the finishing of work.
As ScrumMaster you are here to synchronize your team with others. It is your duty to know dependencies and their status.
How many days till the end of a sprint?
Silly question? Definitely not. It might not be the best idea to let the team open work that they will not be able to finish up to the working stage. What should you do instead? Maybe you have just found a time for cleaning up your code, environment, a time for research or just time to help your colleagues!
Doesn’t make sense? You might be right. Be prepared for user story split, cloning, discussions, new planning, a game with a number of story points (should they be split as well?), etc. But it really might make sense, so be careful about that.
To overcome such a heap of questions maybe you should split your large user stories into smaller ones so you can finish them in 2-3 days with tests, documentation and deployment.
