Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

A story point is an estimate of the relative complexity of a story.

In GreenHopper, you can choose to perform estimation for each board based on either Story Points, hours, or any other numeric field of your choice — see Configuring Estimation and Tracking.

(info) In GreenHopper, story points are implemented via a custom field called "Story Points". For more details please see GreenHopper JIRA Configuration.

37 Comments

  1. Anonymous

    Mar 05, 2012

    Ok,

    I give up, I can't undestand the difference in JIRA between 'story points' and 'original estimate'. Why these 2 don't get unified?

    If I change my OE then I have to change the SP to keep them synched. Statistics and markers work only on SP and not on OE. So some features only work with SP and others only with OE.

    I could end up planning a sprint of 20 SP, when in fact all the sprint's issues OE's are > 20 story points.

    Help please.

    1. Nicholas Muldoon [Atlassian]

      Mar 06, 2012

      Hello,

      The original estimate is a field for time estimates - hours by default. As you want to estimate and burndown stories using Story Points you can disregard the Original Estimate and remove that field from the cards.

      Thank you,

      Nicholas Muldoon

      1. Anonymous

        May 17, 2012

        Can I use OE instead SP on Scrum Rapid Board - Plan?

        1. Shaun Clowes

          May 18, 2012

          Absolutely, in GreenHopper 5.9.7 and above you can choose OE to be your estimation statistic. 

  2. Anonymous

    Mar 07, 2012

    Thanks for your reply.

    Unfortunatelly 'improvements' & 'bugs' i.e. do not have 'story points'. So I am unable to plan sprints based on story points unless everything is a story.

    That's a problem because a bug might need 2 story points to be fixed... How do you solve that?

    Regards

  3. Anonymous

    Mar 12, 2012

    Same problem here. Why isn´t it possible to add story points on bug and improvements? This was possible in earlier versions.

    Please reply to this!

    1. Anonymous

      Mar 21, 2012

      Bugs, by definition, are not usually estimatable and fall outside the story pointing framework.  They are sprint overhead

    2. Anonymous

      Mar 21, 2012

      If they are estimatable it sounds like a story.  Try rewriting based on that perspective.

      1. Anonymous

        Apr 10, 2012

        This doesn't make a lot of sense.   The product goes to QA, the QA team finds and files a bug (in Jira) that says something like "NullPointerException encountered when user clicked XYZ button with 123 value in field ABC".

        It may be very readily estimable that this bug will take 2 hours to fix.   Why should I not be able to plan that into a future sprint?   How can such a thing be a user story?

         

        1. Anonymous

          Sept 10, 2012

          My approach to date is that a bug is reported as "bug" in Jira. When development come to address the bug then it is transformed to "story" at which time the story points can be estimated.

          eg. Bug: "NullPointerException encountered when user clicked XYZ button with 123 value in field ABC"

               gets transformed to

                Story: "Fix NullPointerException encountered when user clicked XYZ button with 123 value in field ABC"

  4. Anonymous

    Mar 22, 2012

    Some teams prefer to estimate their defect work, especially PLANNED defect work.  While I agree it's not the norm, I can't see why there would be such a restriction.

    1. Anonymous

      Apr 10, 2012

      Agreed, many bugs ARE very estimable.   And many bugs sit in a backlog until some future release (and its sprints) are planned.   Sure would be nice to be able to assign story points to any type of issue if one desired to do so.

  5. Anonymous

    Mar 26, 2012

    Yep,

    bugs are outside the 'story point' scope, but what about improvements? ok, you could reword everything into stories, but how do you find out how many bugs you make in a sprint?

    Some teams do actually plan bugs and you may have delivery dates for bugs etc. It should be an option to opt-out of a die-hard scrum approach and try to make it flexible to 'real' world needs.

    Just a suggestion.

  6. Shaun Clowes

    Apr 12, 2012

    Please note: GreenHopper does not try to force Story Points to only be used for certain issue types. By default the Story Point field that GreenHopper creates is only associated with the Epic and Story issue types but you can configure the field to be associated to other issue types as you require. 

    At present the Rapid Board can only edit the Story Point field if it is the exact one that was created by GreenHopper (there may be multiple Story Points fields configured in your instance in some cases). We will correct this in a future release. 

    For the Planning Board please refer to the documentation above. 

    1. Arthur Etchells

      Apr 12, 2012

      Are there any specific plans or timeleines to add Story Points to improvements and bugs or allow the Rapid Board to edit Story Point fields that are not exactly the one configured? Is there a GH key I can upvote for this feature request? 

      1. Shaun Clowes

        Apr 13, 2012

        Yes, we are planning on implementing this (actually, we're implementing it in the current Sprint). 

  7. lvz

    May 07, 2012

    Did this make the current Sprint? We need story points for bugs to be able to view our velocity.

    1. Arthur Etchells

      May 07, 2012

      +1

      1. Shaun Clowes

        May 07, 2012

        Hi, 

        Please see my comment above, you can use the Story Point field for bugs today, just edit the Field Configuration in JIRA to apply the Story Point field to the Bug Issue Type. 

        GreenHopper 5.9.7 (which will be released in the next week) will allow you to use other numeric fields for the estimation statistic (which will be useful if you have multiple 'Story Point' fields configured for some reason). Again, this will not automatically associate the Story Point field with the Bug issue type, you will still need to do that manually as above. 

        Thanks,
        Shaun 

        1. lvz

          May 08, 2012

          We have Story Points enabled in the Field Configurations in JIRA and enabled in Card View for Greenhopper. It's not displaying. 

          1. Shaun Clowes

            May 09, 2012

            Hi Ivz, 

            Are you sure you have set the 'Story Point' field to be associated with the Bug issue type on the "Custom Fields" page of the JIRA Administration screen? 

            If so, please check you are using the latest version of GreenHopper (5.9.7) and JIRA. You may need to re-index and restart. 

            I'm confused about the 'Card View', this is not used by the Rapid Board. 

            If you still cannot get this to work after trying the above, please log a support ticket and they can try to help you work out what's going on. 

            Thanks,
            Shaun 

  8. Anonymous

    May 08, 2012

    You should not allocate points to Bugs.

    Why ? Because a bug corresponds to a defect impacting a feature you already allocated points to when you developed it. So your product Owner has already paid for it. A Bug is zero point. And yes you can imagine a sprint whose product backlog is made of bugs only. Your velocity will be 0.

    No problem with this. Here QA will bring other metrics related to impact of your sprint considering the Business Impact and Severity of each bugs and then

    give value to your scrum iteration.

    1. Arthur Etchells

      May 08, 2012

      Agreed, typical scrum methodology suggests that bugs should not be assigned story points because they shouldn't be counted in velocity.

      In actual fact for some team's, this can create the following problem:

      I think the debate arises from having two different measurement purposes collapsed into velocity. These purposes are determining 1) how much customer facing value is being delivered 2) increasing estimation accuracy for decision making.

      Not including points for bugs and chores allows monitoring customer facing value as the primary measure. But, it reduces accuracy of estimates and therefore decreases the ability of the project manager to decide which task to do next.

      I personally have been bitten by the inability of estimating refactorings that are categorized as chores. Yes, it's good to do refactorings as soon as possible, but it's good to know the relative point cost in comparison to customer facing value when working against hard deadlines.

      I think the best solution would be to give points to bugs and chores to allow for more accurate cost based planning and have separate measures for total velocity and feature velocity.

      http://community.pivotaltracker.com/pivotal/topics/bugs_and_chores_should_be_estimable_without_counting_toward_velocity

       

      In my team's workflow, it's more helpful to view Story Points as an indicator of required effort to resolve - solely as an estimation tool rather than measuring user-facing value.

      In this alternative formulation the impact of bugs can be viewed as the story points (developer effort) consumed by bug issues, rather than the reduction in velocity due to bugs. In your proposed methodology, how would you plan a sprint if you as the scrum master have no visibility as to the likely effort required by each bug? You might answer with something like 'estimated time,' but while this is a first-class citizen in JIRA, it isn't in Greenhopper or Scrum methodologies (and I would argue both are much the better for it).

      1. Anonymous

        Jun 18, 2012

        We are starting Scrum process with legacy code with tons of defects that are not fixable in "chores"-like time. Estimating them in Story Points would allow us to measure the velocity in terms of enhancements AND defect fixing, and Product Owners should also pay for Technical Debt that they pushed into non-scrum teams, so there are some scenarios where estimating defects in Story Points is indeed a reasonable way to proceed.

  9. Anonymous

    Jun 25, 2012

    We use story point estimation for anything that we plan to do. If an emergency support issue has to be tackled we just do it (though check if it can wait for the next sprint plan) and it then becomes one of the factors that reduce a team's velocity. Since we have taken this approach, the vast majority of support bug fixes can be deferred to the next sprint planning where business value and story point estimation can help prioritise.

  10. Anonymous

    Aug 13, 2012

    Note that if you are looking for the story points option to appear in the list or summary view of a bug on the Greenhopper planning board apart from all the other good advice listed you need to ensure (or at least it worked for me) that the story points option is selected as the field at the bottom right of the card view as well.

    So go to Administration>Greenhopper>Project templates

    Now under the project templates heading select the relevant template (in my case "Scrum", not "Default")

    Under the Card Styles heading select Issue Type "Bug"

    Now in the card view make sure that the field at the bottom right has "Story Points" selected from the drop down list.

    This should automatically result in the other views containing the Story Points field, whereas if you only add "Story Points" as a field to the list view, as I did, it may not show up on the planning board list view.

    -Monty

  11. Angie Schiavoni

    Oct 09, 2012

    Okay two questions:

    1) Why is the story point field so big? It is currently a large text box but shouldn't it be a numerical field and only allow a few characters?

    Which sort of relates to my next question:

    2) How do I get it to show up on my list views (i.e. my issues navigator - issues table views)? When I click "edit filter's column order," I can choose it from the list of fields (although it looks huge and takes up a ton of vertical room because of it's text field size), but when I go back to the list view it is not there.

    Thanks!

    1. Shaun Clowes

      Oct 09, 2012

      The size is just the way JIRA renders the field, it is definitely a numeric field but GreenHopper can't control that sizing. 

      It should show in the your Issue Navigator query but only if every issue in your list has that field, so for example if you include Bugs in your issue navigator (which by default don't have the Story Point field) then the column won't show. 

      Cheers,
      Shaun 

      1. Angie Schiavoni

        Oct 09, 2012

        Thanks so much for the quick response.

        I use story points for both bugs and stories (I know this is frowned upon by the true agile folks and those at PT, however, I find it important for accessing the true velocity of my team). So I just need a way to see those numbers on the list views and make sure they add up to our velocity number each iteration. It's a real bummer if I can't seem them because I can't adjust my iterations when new stuff comes in.

        Is there a way I could use another field as a work around or do you have any other ideas?

         Again, thanks.

        1. Shaun Clowes

          Oct 09, 2012

          This should just work, see the note in the documentation above about associating story points to bugs. If all of the issues returned by your issue navigator query have the story point field it should show in the column. 

          One way to be sure that all the results have a Story Point field is to use a filter like "'Story Points' != empty"

          Thanks,
          Shaun 

  12. Anonymous

    Oct 16, 2012

    How do I track my actuals for story points? I'd like to keep track of how good we are at estimating points.

    And thank you, this thread has been very helpful. I was able to enable story points on all issue types, and to add them to issues in the planning stage (and to remove issues from the sprint to add the story points, and put them back in...).

    1. Nicholas Muldoon [Atlassian]

      Nov 16, 2012

      Hello,

      Please use the Velocity Chart to track actuals vs planned for your sprints.

      Thanks,
      Nicholas Muldoon
      @GreenHopperTeam 

  13. Anonymous

    Nov 15, 2012

    Hi, will you be introducing the ability to use different estimation types for different issue types?  And also porting over the ability to have both burndown charts - Storypoint and Hour burndowns.  We find both of these very beneficial to the teams.  At the minute on the Scrum Board you can only have either Story Points or Hours.  Both are needed - just on different issue types.d

     

    1. Nicholas Muldoon [Atlassian]

      Nov 16, 2012

      Hello,

      Can you please explain how you would use different approaches to estimation for different issue types. How would you expect the estimates to roll up?

      If you have Time Tracking turned on for your board you will see an hour burndown chart. Instructions can be found on Configuring Estimation and Tracking. A full explanation of the reasoning behind the estimation can be found on the blog Agile Q&A – GreenHopper Time Estimates with Sub-Tasks.

      Thanks,
      Nicholas Muldoon
      @GreenHopperTeam 

  14. Simon Davies

    Jan 03, 2013

    Is it possible to display the total story points for the entire Backlog in Greenhopper (I am not using the classic planning board, but the new style GH agile board)?  It shows totals (per status) for the current Sprint but not for the Backlog items.

    1. Rosie Jameson [Atlassian]

      Jan 06, 2013

      Not at this time, sorry. You may like to vote/watch/comment on GHS-3676 - Getting issue details... STATUS

  15. Emmanuel Szabados

    Jul 30, 2013

    We use a new custom field for bug estimation: "Bug Points" even if bugs are not easy to estimate... But it would be great to see it in a Burndown as a new line if we wanted (distinct from Story Points). Bug Points could be set as a generic field in Green-hopper like Story Point for those who want to use it.

    As well it would be great to see it in the Plan view: Total Bug Points not started...



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Tweet, blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.