Skip to main content
Back
X
Back

Scrum Forum

How to measure productivity of my Scrum Team?

Last post 10:18 pm September 1, 2015
by Anonymous
10 replies
Author
Messages
01:15 am December 27, 2013

How to measure productivity of my Scrum Team?
Example:
Starting from Sprint 1 team assumes some velocity for them self
Team test their strength in couple of Sprints
Team found their Sprint Velocity
Let’s say my teams Velocity is 40 Story points per sprint
I took a story for 8 story points in Sprint A
I again got similar story in Sprint 5 and this time I estimated the story for 5 story points means I can accommodate 3 more story points in that sprint but eventually my teams velocity will be 40 only.
How can I show the improvement of 3 story points in my productivity graph?

03:08 am December 27, 2013

In Scrum productivity is measured in terms of actual delivery, not story points. If an increment if value is produced in accordance with a Sprint Goal which satisfies the Product Owner, then success is being achieved.

Story points are for helping teams forecast how much work can be taken on in a sprint. The tracking of story point burndown is not to measure productivity, but rather to show how much work remains in a backlog.

04:52 am December 29, 2013

Hi Ashurai,

Why is measuring team productivity is important to you? What problems are you trying to solve?

02:06 am December 30, 2013

Hello Ashurai

Scrum is not about delivering more but delivering ONLY features which customer wants. I would recommend to use different metric to measure your team productivity -

1. Thumbs up from stakeholders to the new increment
2. Unit test coverage
3. Continuous Integration status
4. Team Happiness Index
5. How long does To-Do to Done take?
6. Customer Reported Defects
7. Feature Usage Index

Cheers
Sanjay

03:07 pm January 9, 2014

The last word on page 12 of the scrum guide is probably the most important one but is seldom followed. That word is "Value".

"The Product Backlog lists all features, functions, requirements, enhancements,and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and VALUE"

I have almost never seen "VALUE" in a product backlog item. Story points are good indication from a project management perspective but from a business perspective it is the Value produced by each sprint that is probably the right indicator of productivity ...

11:21 am January 10, 2014

Ashurai,

As Sanjay pointed out, although productivity is important, Scrum is not about delivering more.

I recommenced reading a little article, The Deadly Disease of the Focus Factor.

It might help you think about productivity in a way that better serves your team.
https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl…

Best,
Daniel

10:34 am January 11, 2014

Very good point Sandeep. Problem with defining value is that you have no idea of the value until your customers are using it. You can guess that feature A has twice that value as feature B, but until you have built, shipped and gathered feedback you're really guessing.

Also, the relative value is also kind defined by the order of items in the backlog. If two items are estimated the same, the one with higher value should normally be ordered first.

11:03 am January 11, 2014

The "value" attribute of a Product Backlog Item is perhaps best seen in terms of risk reduction. Using MoSCoW priority as the attribute is one way to express value and it can certainly help to inform a Sprint Plan.

Trying to anticipate value is indeed very difficult...as Fredrik says you really have to ship something first. That's why it's important to keep batch sizes small and to release frequently. In an agile way of working a product should be its own market research tool.

11:55 pm May 22, 2014

Have come across the need to measure team's productivity primarily wrt code quality delivered by them when working with different teams (belonging to different vendors). Based on our experience, we found that measuring code quality attributes such as defects density, code complexity, code coverage etc vis-a-vis velocity throws some interesting light and patterns which could be helpful in measuring productivity to some extent. Thus, went ahead and put up a software quality metrics tool for everyone to try and see if it could be helpful. Do check http://agilesqm.appspot.com.

02:32 am May 23, 2014

I have one question... as you do relative sizing, why is a similar story 3 points less.
By using story points you should compare stories and if they are similar they get the same points. Than you also may can see an effect of good or bad practices through your velocity. By sizing them differently you can not see this effect

BR,

10:18 pm September 1, 2015

Posted By Philipp Eisbacher on 23 May 2014 02:32 AM
I have one question... as you do relative sizing, why is a similar story 3 points less.
By using story points you should compare stories and if they are similar they get the same points. Than you also may can see an effect of good or bad practices through your velocity. By sizing them differently you can not see this effect

BR,

Size is an ambiguous term, and depending on the project can incorporate different things, such as number of units, complexity, technical risk, etc. I'm guessing it's possible that the relative size of a similar story diminishes over time because there may already be some reusable base code for it (less complex), or the technical risk drops due to familiarity with the Story goal.