Get certified - Transform your world of work today

Close

How Story Point Estimation Can Help Managers

21 August 2015

Jipson Thomas
Thomas Tech Services Limited


In the world of Scrum, we have only three roles: product owner, ScrumMaster, and the team. But in reality, we could have a manager who might be internal or external to the Scrum team. In this case, we think of our manager as our stakeholder or business partner, or the one who owns the project team. As a manager for the team, the person should always be curious about the productivity and the performance of each team member and of the team as a whole. So in this article, we will consider how story point estimation can be used to validate team performance.

A user story is a collection of tasks for the team to complete, and the story point estimation is the measure that represents the complexity or effort required to finish the story. A story point estimation can be sized based on different factors such as dependencies, external resources, impediments, etc. Therefore, it might not be a good idea to measure a team member's productivity or performance based on story points. Because user stories are completed by the team, I support the use of story points as a good measure for evaluating the performance and productivity of the team.

The term velocity that is used in Scrum is the total story points achieved by the team by the end of each sprint. I agree that for the initial sprints on the journey to being Agile, it shouldn't be an accurate value, but we should gradually become more accurate after each sprint. To get a more accurate velocity measure of the team, we must make sure that we have a good Definition of Done, a strong story point estimation method, and that we use the historical data cleverly during sprint planning. Another important point is to have the simplest user stories to estimate. That doesn't mean that you do only the simplest jobs but that you should avoid calculating estimates on epics.

By checking the story points and velocity charts, managers should be able to plan the new releases more effectively. So I strongly recommend that you use story point estimation accurately and regularly to improve the productivity and performance of each Scrum team. This estimation will bring a bright future to you and your organization by helping you use Scrum effectively as you become more Agile.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.9 (14 ratings)

Comments

Vincent Vollero, CSM, 8/25/2015 8:39:56 AM
Hi Jipson,

What is your thought about the team writing stories for production support issues (i.e. unplanned activities) that come up during the sprint, and assigning points to these stories?

Thanks,
Vincent Vollero, CSM
Damián Buonamico, CSD,CSM,CSPO,REP, 8/25/2015 3:37:49 PM
I don't understand how the Scrum Alliance allow this kind of suggestions in their Official Website.

You should never make use of Velocity tool for a Manager to assess the Team Performance. This will easily lead to Point Inflation and kill the utility of the tool. Velocity can be only be used by the team itself for planning purposes, never for performance.

Scrum Team should aim for Outcomes. Large output is not a measure of performance.

Furthermore, this article is extremely short and I don't see any value out of it.
Parashuram Bellikatti, CSM, 8/28/2015 10:12:59 AM
Absolutely Agree with Damian's views. velocity should be used for planning purpose not for performance or efficiency. Velocity is a good artefact for planning time-boxed releases and also to plan an iteration from a capacity perspective.
Alan Dayley, CSP,CSM,CSPO, 8/28/2015 3:31:09 PM
So much dysfunction in this article.

"...a manager who might be internal or external to the Scrum team." All members of a Scrum team should be peers, not managers of anyone else on the team.

"... used to validate team performance." Because delivering working software every Sprint or getting closer to being able to do so is not a way to validate performance?

"A user story is a collection of tasks for the team to complete" Incorrect.

"A story point estimation can be sized based on different factors such as dependencies, external resources, impediments, etc." The primary reason to use story points is to help us size one piece of work relative to another piece of work. The factors listed may be considered but ONLY in the context of how they are more or less relative factors to other user stories.

"but we should gradually become more accurate [in velocity] after each sprint." No, you will not. You will become more predictable. The velocity number INCLUDES the inaccuracies of user story sizing. Such inaccuracies do not go away. The increase in predictability means we don't have to strive for more accuracy. As long as we plan our next sprint according to our recent past velocity, accuracy is not needed.

"By checking the story points and velocity charts, managers should be able to plan the new releases more effectively." Managers are doing the planning? Where in Scrum and Agile does it say that managers do the planning? Maybe you mean someone different than I do when you use the word manager. Certainly there are many people involved in different kinds and levels of planning. This statement implies to me that someone, managers, are planning for the team. This is an incorrect view. Maybe I am assuming too much in the statement.

(I remain baffled as to why articles like this appear on this site. I guess we don't have editors or reviewers who understand Scrum and Agile principles. What a shame.)
Tim Baffa, CSM, 8/31/2015 4:43:54 PM
Vincent, the team should -never- add stories to an accepted sprint offer to account for additional work being performed within a sprint.

The sprint backlog is not a task list representing how busy the team actually is. The only items that should appear on the sprint backlog are stories that provide value to a customer (internal or external).

As a Scrum Master, you should be working with the team (and the business) to brainstorm ways to reduce or eliminate any distractions to the team during a sprint. This includes production support issues. What you should -not- be doing is recording these non-sprint efforts by the team as new stories in the backlog, and then asking the team to estimate this effort. A completely wasteful exercise.

The -only- time a sprint's scope should be changed is if it is agreed to between the product owner and the team (add/remove stories).

I'm not saying that the business should not be aware of the capacity hit the team takes when working on production issues - transparency is key. But such disruptions should already be factored into the team's capacity when evaluating the sprint offer.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe