Often organisations new to Scrum and trying to implement it struggle with the Scrum Master role. I mean; its a person who the team does not report too, yet they are responsible for the process and getting things done. Its not just the organisation, people new or transitioning into the role often have these problems too.
A good Scrum Master will not insist that all information goes through them, they are not a conduit or an approver and should not act like a filter or a funnel in an organisation. …
A very important role of the Scrum Master is to protect the team.
This can come in many forms such as uneducated stakeholders or over eager product owners. I have highlighted two things below which I think are important for the Scrum Master to protect the team from.
Remind yourself why you initially decided to implement Agile or Scrum, most likely it was so you could get better. Scrum is all about getting better iteratively and persuing continuous improvement. …
Someone once told me this great analogy for estimating story points.
Image you have a well where you take water, and you need to transport 10 litres of water back to the village. You have a 8 litre bucket and a 13 litre bucket. Which do you use to transport the water?
We all know everyone doesn’t like meetings.
A good tip to save you some time is to not do the Sprint Planning on the day of Sprint Planning. What you should actually do is spend a few minutes at the end of the Sprint Planning meeting to discuss the first things that will be tackled during the sprint. With this, everyone will leave the meeting with a sense of purpose.
This doesn’t need to to be an actual daily stand up, there should be no impediments or they do not need to go through what happened since the last stand up. …
We have all been in the situation; you discuss a user story, you have a pretty good understanding of how it needs to be implemented in the system. Then when you start to work on it, you realise more work needs to be done.
Its a common practice, when you originally estimate its at a pretty high level, then when you actually get into the detail and further clarifications are made — scope can often increase.
A good technique that I have used many times is to create a checklist of areas to consider each time you estimate. This would be a living list which would grow as new considerations come up during the sprint, each time a user stories estimate grows…. …
See below some key indicators that you are not implementing scrum at its highest efficiency:
Your scrum team are no longer performing the Sprint Retrospective. This means your team are no longer focusing on continuous improvement of have any kind of plan in place to speed up delivery time.
Whenever an agile practitioner is selling reasons to adopt an agile approach; in general or one of the the specific methodologies like Scrum, Kanban or XP, they always focus on the benefits (as they should).
These usually include:
These are all very important things to consider, and when you think about it, these stand out because they actually impact the working lives of people within the organisation. There are the obvious business benefits such as improving speed of delivery, reducing turnover of employees, keeping your most highly skilled employees engaged and reduced cost; but these impact the lives of the people in the company directly — making them a lot easier to identify with. …
Working in an industry that is faced paced and has a strong business push can be both exciting and stressful.
The ability to deliver quickly, to beat your competitors is always there, and Scrum teams work hard to optimise their processes, deliver quickly and to a high quality.
As a Product Owner, you for sure have the pressure to deliver, but you also need to ensure that the scrum team doesn’t burn out.
I think its sometimes a good idea to let your team recharge after a while, especially after a long stretch or a large project has been delivered. …
Most scrum teams will estimate their tasks during the Sprint Refinement / Grooming meeting.
This is ok, actually its a great time to do it. You have all the members of the team together in one room and its a good opportunity to break down users stories and make sure everyone is on the same page.
Some teams (and my preference too) is not to have the whole team at these events. Some teams have this as a one or two our meeting. I think its OK to do this but often its unnecessary to take the whole team. A third of half the team is probably sufficient, and this way you can keep team member participation in meetings down (if you rotate attendants, or invite who you think has the best understand in a particular area). …
Do you often get visitors to your daily stand up?
I have worked with scrum teams where ‘outsiders’ like to attend and see whats going on. Sometimes they are just silent observers who just like to see whats going on, but do you ever get visitors who start to contribute, butt in, even disrupt the meeting?
If you are a scrum master, how do you deal with these scenarios, what if the visitor is a senior manager or the CEO? Should you tell them to be quiet?
Often you might find that these visitors are not familiar with scrum, or specifically the format of the daily stand up. You obviously don’t want to be rude, or make the visitor feel uncomfortable. I mean it should feel nice that the CEO is taking an interest in what you are doing and you would not want to ruin any goodwill that they currently have. …