Not able to enter estimates for "bugs" and "enhancement" issue types in Greenhopper

[Jeff Scarsbrook]

When I look at my Jira tasks in the Greenhopper Scrum Board, I don't have the option to estimate the issues when the issue types are classified as "bug" or "enhancement". It works fine if I change the issue types to "story". I know that by default the Greenhopper Scrum Issue Type Scheme doesn't include "bug" or "enhancement". However, I went in and added them to that scheme, as shown in the link below:

http://s8.postimage.org/rxyifyhc5/Jira_Priorities.jpg

Everything I see is telling me that I should be able to estimate the issues in Greenhopper with my current set-up. Does anyone have any ideas?

[Tao Klerks · Accepted solution]

I came across this same issue while setting up my boards today - turns out the limitation is at the Field level. To resolve:

• Administration
• Issues -> Custom Fields
• Find "Story Points", on the cog at the end click "Configure"
• Click "Edit Configuration"
• Under "Choose Applicable Issue Types", make sure that all the types you want to be able to estimate are selected (use Ctrl-click to choose several in windows), and then click "Continue"
• (not sure whether reindexing afterwards is useful or not, but I did)

Voila, you now have estimate boxes on those additional Issue Types. (or at least I did!)

Now as to whether that's something you want or not, there seems to be some debate:

• http://www.mountaingoatsoftware.com/blog/should-story-points-be-assigned-to-a-bug-fixing-story/
• http://www.agileforall.com/2010/05/05/agile-antipattern-sizing-or-estimating-bug-fixes/

[Jeff Scarsbrook]

Tao, thanks for the idea. I changed the Story Points options, but it's not necessarily working the way I would expect still. I now see the field Story Points on the issue if I edit it in Jira. The sub-tasks show in Greenhopper on the Scrum Board as "children" of the parent task, which I suppose makes sense.

It could just be that Greenhopper doesn't handle things the way that would make sense logically to me, so it's possible (and maybe even likely) that Greenhopper is working the way it is intended. This is what I would expect, however. At the very least, the story points for the parent field in Greenhopper (as shown to the right of the task) should be the computed total of story points entered on the sub-tasks. Also, we should be able to enter the story points on the Greenhopper screen (similar to the way that they are entered for tasks). Also, the way the screen is working now, you can't put separate sub-tasks in different Sprints. It's not a completely crazy idea that you could have one large issue, which is broken down into multiple smaller issues that will be worked by different developers and delivered as part of different sprints (what if one sub-task requires other sub-tasks to be completed first, and thus delivered at different times, or if one sub-task just has more work than another). In any case, if this is a case of Greenhopper's design not fitting my expectations for this type of thing, I'd appreciate if somebody would confirm that, so I don't waste more time on this.

http://s12.postimage.org/m44z1h8tp/Scrum_Board.jpg

[Tao Klerks]

As I mentioned I'm no scrum expert, but based on what I've heard and read so far (so far best reference = "Essential Scrum", by Kenneth S Rubin), there are a couple of things "wrong" in what you're saying:

Product Backlog Items (eg User Stories) should be placed individually on the product backlog. If you are looking at completing a single story/PBI over several sprints, then you haven't broken down your PBIs enough (to sufficiently small stories/items).

The Sub-tasks in JIRA are used exclusively, in Greenhopper, to represent the "technical tasks" (optionally) within a User Story. These "technical tasks" typically wouldn't get story points, they would get technical estimated time, determined during sprint kickoff. The problem with assigning story point units to technical tasks is that you end up mixing apples (high- to mid-level effort estimation) and oranges (technical work detailed estimation).

For me, the natural question is then "but I have an epic/theme/feature, where all the user stories belong together - the delivery of one without the other is pointless, so I need a reliable way to see all the user stories that comprise that one epic/theme/feature". So far, the only ways that I've seen to handle this in Greenhopper are the "Labels" field or the "Epic/Theme" field (basically a specialized "Labels" field - it wasn't assigned to the issue display screen by default, I had to add it).

[Tao Klerks]

No problem! with respect to "Sub-Task" vs "Technical Task", this seems to be a "Regular Jira" vs "Greenhopper" distinction. If you use the "GreenHopper Scrum Issue Type Scheme" type scheme, you'll find that "Sub-Task isn't there (by default), you only have "Technical Task".

[Jeff Scarsbrook]

Tao, I understand where you're coming from. Here's an example of one piece of work that might be like your point about individual tasks that were pointless without the others. We are looking to re-write an existing web site, as part of a re-factoring effort, and a move to a more services approach. Obviously, we can't migrate completely from our current site to the "new" site until all of the existing functionality has been ported over. We will have multiple people working on this effort, so obviously there would need to be individual tasks/sub-tasks/stories so they can be assigned to different people, since you can't assign a single story to more than one person in Jira. This total effort will span multiple sprints, but we plan on working in stages so that we should be able to complete individual pages/parts of the web site and move them up as they get completed (especially since some of the new services will be used by other stories that we have on our plate). Essentially, I was looking for some sort of a concept where there was an over-arching "parent" with mutiple "child" tasks. The individual children could get worked independently (in different sprints perhaps), but the "parent" isn't considered done until all of the "children" tasks are completed. I suppose I really am just talking about a way to "group" a bunch of like tasks/stories, and it appears labels would accomplish that.

I know that in Jira, they have "technical tasks" and "sub-tasks" as the two available types of "child" tasks. I figured the "technical tasks" would be for stuff like database migration, or server set-up, or stuff like that, which I agree is much different than an actual task or story, and thus not worth estimating like you would those types. However, since they went through the effort of creating a separate "child" type for "sub-tasks", I guess I was just trying to figure out what they had in mind for what a "sub-task" is in their world.

Thanks!

[Jeff Scarsbrook]

Of course, I couldn't find this earlier in the documentation (another example of how things are easier to find once you don't need them). This is from the Greenhopper documentation:

Why not estimate on sub-tasks and roll that up for Velocity and Commitment?

Many teams break down stories into sub-tasks shortly before the sprint begins so they can use the stories for tracking. This raises the possibility of using the sum of the estimates on the sub-tasks as a way to decide which issues to commit to in the sprint (and potentially for velocity).

As described above, tracking is really a separate process from estimation and velocity. The estimates that are applied to the sub-tasks are clearly higher accuracy than those that were originally applied to the story. Using them for velocity would cause the velocity to have both high and low accuracy estimates, making it unusable for looking looking further out in the backlog where stories have only low accuracy estimates. In addition, only items near the top of the top of the backlog are likely to have been broken into tasks, so using task estimates for velocity means that the velocity value could only ever predict the time to complete the backlog up to the last story that has been broken into tasks.

Using the sub-task roll-up to decide the sprint commitment would also be dangerous because, unlike the velocity value, it does not take into account the overhead of unplanned work or interruptions.

So, it appears that they purposely didn't design the sub-task concept to roll up to the parent level for stories. After reading their explanation, I suppose I understand why they went with their approach. I agree that the key to having a useful velocity (and velocity is a critical measure to know) is for everything to be estimated with the same level of accuracy (or inaccuracy).

[Tao Klerks]

wrt estimating sub-tasks, my understanding is that this is typically something the scrum team does at kick-off, creating the sub-tasks as they go; the sub-tasks don't appear as story points, just as "Work Pending". I'm very new to scrum and haven't successfully cycled through any sprints yet though, so take what I say with a grain of salt.

[Jeff Scarsbrook]

Anybody have any ideas? Also, if you create sub-tasks, shouldn't you be able to estimate the sub-tasks individually? If I create sub-tasks for a story, then I don't see the sub-tasks on my Scrum Board, so there's no way to estimate the sub-tasks independently.