How should a scrum master track sprint progress?

How should a scrum master track sprint progress?

Welcome to part 53 in our scrum master interview question series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.

Why should a scrum master track sprint progress? How they do it is a matter of logistics, but they aren’t project managers who are DRIVING outcomes. They aren’t there to crack the whip and tell the team to deliver. They aren’t in the delivery at all, so why should they track progress?

If it’s something that you want to do, as a scrum master, use an online tool or a spreadsheet and that should be more than sufficient to get the outcome you are looking for.

What is sprint progress?

Sprint progress refers to the amount of work that was planned for the sprint and included in the sprint backlog versus how much of that work has been completed or delivered.

Say 10 items were included in the sprint backlog and your team have completed 5 of those items, sprint progress would be 5 items or 50% of the sprint backlog completed.

Again, this stuff isn’t hard. I honestly don’t know why this would be an interview question but I’ve seen worse, so well attempt to help you form some kind of a reasonable answer.

Forecasting.

If 50% of the sprint backlog items have been completed, you could ask the team how they are progressing with regard to the balance of the items.

The reason scrum masters don’t do this, generally, is because the developers are professionals that are aware of what needs to be done, how best to do it, and are deeply invested in delivering against their sprint goal.

Sitting them down for 30 minutes to ask how they are coming along is a waste of their time and in those 30 minutes, nobody is doing any development work or solving any problems. In this scenario, the impediment to progress is you, the scrum master, for having a meeting about productivity instead of letting them get on with it and deliver outcomes.

The work they are doing is hard, it is also complex, and in most scenarios they would never have built this item before or solved that problem before, so it would be impossible for them to tell you how long an item will take to complete.

They will only know how long it takes when the solution has been built or the problem has been solved. Asking them beforehand is a waste of everyone’s time and it annoys people because they can’t give you the answer you are looking for.

So, if you absolutely must forecast, for whatever reason, simply look at the burndown chart over the past few months. If they deliver 5 x large items in a sprint, and 15 medium items, and 20 small items, you can start to forecast yourself.

The team average 15 medium items in every sprint, you have 10 medium items on your sprint backlog, and so it seems reasonable that the team will deliver your 10 medium items by the end of the sprint.

You can forecast that the items will likely be completed, barring an impediment or organizational policy that is blocking them, by the end of the sprint. Same as the last sprint and the sprint before that.

If you want to get fancy, you can take the 10 items and divide them by 10 working days in a sprint to forecast that you will deliver an average of 1 item per day.

If I were asked this question in an interview, I would explain to the interviewer that my role as a scrum master is to help create an environment can excel, and to intervene when someone asks me to help remove an impediment that is beyond their influence and control.

I would explain that a scrum master does not work in the same way as a project manager, we don’t fill out Gantt Charts and chase people down, our role is to support them, teach them, coach them, and facilitate great events that allow the team to thrive.

I would ask them what their understanding of a scrum master role is, and answer as best I can based on their knowledge and understanding.

You don’t have to be rude or sarcastic, it is simply a matter of educating the interviewer about the difference between a scrum master and a project manager. It’s letting them know that the developers are autonomous and are tracking their progress on their own, without the traditional carrot and stick to incentivise them to do their job.

About John McFadyen

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster

author avatar
John McFadyen Managing Partner
John McFadyen is an Executive and Enterprise Agile Coach with proven experience working on some of the UK and Europe’s largest, most complex Agile Transformations. As a Certified Scrum Trainer, John brings a wealth of experience as an Agile coach, Agile practitioner and software developer into each of the four core courses he provides. The war stories, the insights into successful Agile transformations and everything he has learned from coaching high-performance Agile teams combine to provide course delegates with a unique, compelling training experience that transforms as much as it empowers.

Like this post? Share with friends & colleagues using the share buttons below.

Facebook
Twitter
LinkedIn

Related Blog Posts

Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen