Is ScrumMaster Time Tracked in Sprints?

6 May 2013

Hubert Smits
SmitsMC

I recently was asked this question: "Typically, does the ScrumMaster have stories in any given sprint that track for iteration planning, backlog refinement, or any other sprint/Scrum tracking activities? Or does the ScrumMaster's time fall outside the velocity for the Scrum team?"

These are actually two questions, and there are some interesting assumptions within the topic. First, regarding ScrumMaster activities: Like other process and incidental activities, I do not write stories for them. Examples of these activities are holidays, support, training, and also Scrum process work such as sprint planning and daily Scrums. This includes such ScrumMaster activities as preparing for sprint planning. During sprint planning, each team member lists the time that is not available for development of new functionality (stories). The ScrumMaster will put some more hours in this bucket, probably twice as much as the average team member. An example of a capacity plan is in this picture.

(As an exercise to the reader, what can you say about this team's size?)

The remaining hours, in the "Capacity" column, are available for stories. When a team tasks out stories, and a team member commits to a task, the estimated hours for the task are subtracted from his or her capacity. Team members (this includes the ScrumMaster) can commit to tasks until their available hours reach zero. (All this is assuming that a team writes tasks, finds owners for tasks, and estimates tasks during the sprint planning).

So the short answer is: "No, do not write stories for ScrumMaster activities, nor for other Scrum team member activities, when those activities are Scrum process activities."

The issue of velocity is another question, and its answer follows from the above explanation. That is, only the size of accepted stories count toward velocity, and since a process activity is not a story, this work does not count toward velocity.

Finally, I'd like to make an observation, which is that the title of this article is "Is ScrumMaster Time Tracked in Sprints?" The easy answer to this question would have been that Scrum doesn't require time tracking, neither from team members nor from ScrumMasters. One method of progress tracking is the use of sprint burn-down charts, which work with estimated hours left to use, not with tracked hours.

Article Rating

Current rating: 0 (0 ratings)

Comments

Scott Friend, CSM,CSPO, 5/6/2013 5:22:57 PM
I am new to the community, so my lack of experience may be evident in the content of this comment. Hopefully if so, it can enlighten the discussions.

The last paragraph was the key. Time tracking is not an element of the scrum framework. Time tracking does not even apply to velocity, isn't velocity the number of estimated story points that were completed during a sprint - only through extrapolation of the team's hours can we roughly relate velocity to team-hours (which I think is a bad idea).

Arguably, a purely dedicated development team would not have members reserving time buckets for support. However the reality is that the team is likely responsible for some Tier 3 type support, and it needs to be removed from capacity. But, these time buckets should be constant for the team's. When a time bucket is under or over utilized, it will have a relationship to the number of tasks completed. This variation is not predictable, over time it should average out.

When talking about the Scrum Master's capacity planning, the Scrum Master is not a developer, therefore he or she should not be completing tasks that count toward the velocity of the development team. In the case that the Scrum Master is wearing multiple hats (which should not happen), then the Scrum Master's development capacity (and utilization) shall be considered.

The purpose of a velocity seems to be for release planning more than sprint planning. When planning a sprint, relative effort points (estimates) do not have any importance. The team should be breaking the features (or stories) down into the tasks, and estimating hours for each of the tasks. The team's capacity for the sprint will apply to making the sprint backlog commitment. This would mean that if a developer were to have a planned PTO day, this would reduce the team-hour capacity.

So, the way I see this is that if the capacity of a team is altered for a sprint, the velocity of that sprint will likely be effected (like running a 12 cylinder car with one cylinder missing will reduce the overall performance). It is a temporary situation for the single sprint. Again, over time it should normalize.

I wonder what others think.
Shane Poole, CSM, 7/5/2013 4:35:58 AM
The simple and quick answer is no.
The team work on the tasks which they created as part of Sprint Planning which help them to deliver the User Stories that they have committed to. The ScrumMaster’s role is to remove any impediments (blockers) that are holding this progress up. The important thing is to track the team not an individual and certainly not the SrumMaster.
I personally see an advantage in tracking both User Story points (bar chart) and Hours (line chart) in the Sprint Burndown as it gives the whole team two perspectives on progress.
Mary Ann Rayla, CSM, 7/10/2013 2:30:20 AM
I agree with Shane. The Scrum Master is only responsible over the scrum process and don't have any involvement in any of the sprint tasks.However, the Scrum Master may suggest on how many points or hours to put on a certain tasks base on experience,effort,complexity, but still the decision is not the Scrum Master's to make, the final words should come from the scrum team.
Bhushan Kulkarni, CSM,CSD, 7/22/2013 3:55:03 AM
I agree with Shane.

You must Login or Signup to comment.