Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

How to measure productivity of my Scrum Team?
Last Post 01 Sep 2015 05:18 PM by Wei Yang. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Ashutosh Rai
New Member
New Member
Posts:1
Ashutosh Rai

--
26 Dec 2013 08:15 PM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1609
    Ian Mitchell

    --
    26 Dec 2013 10:08 PM
    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.
    Joshua Partogi
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    28 Dec 2013 11:52 PM
    Hi Ashurai,

    Why is measuring team productivity is important to you? What problems are you trying to solve?
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:151
    Sanjay Saini

    --
    29 Dec 2013 09:06 PM
    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
    Sandeep Kamat
    New Member
    New Member
    Posts:21
    Sandeep Kamat

    --
    09 Jan 2014 10:07 AM

    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 ...
    Daniel Racowsky
    New Member
    New Member
    Posts:40
    Daniel Racowsky

    --
    10 Jan 2014 06:21 AM
    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/articleId/801/The-Deadly-Disease-of-the-Focus-Factor

    Best,
    Daniel

    Fredrik Vestin
    New Member
    New Member
    Posts:81
    Fredrik Vestin

    --
    11 Jan 2014 05:34 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1609
    Ian Mitchell

    --
    11 Jan 2014 06:03 AM
    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.
    Ajitesh Kumar
    New Member
    New Member
    Posts:1
    Ajitesh Kumar

    --
    22 May 2014 06:55 PM
    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.
    Philipp Eisbacher
    New Member
    New Member
    Posts:35
    Philipp Eisbacher

    --
    22 May 2014 09:32 PM
    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,
    Wei Yang
    New Member
    New Member
    Posts:1
    Wei Yang

    --
    01 Sep 2015 05:18 PM

    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.
    You are not authorized to post a reply.


    Feedback