Using Jira with Story points - couple of questions

Question

Dear fellow-users,

Hope someone can shed some light: we're using Jira in our scrum team. We decided on using Story points given the fairly wide spread in experiences: it allows us to keep the estimate, independent of who will take on the task.

Our questions:

- when dragging an issue on the Kanban board to the "Done" column, remaining story points are not set to 0. If doable, how can we achieve this?

- The Kanban board shows remaining time instead of remaining story points. Can't figure out how /where to change this either.

Thanks! Peter

Nic Brough -Adaptavist- · Answer

I don't think it's using Jira "improperly" at all.  You're adapting what you've got because the tool is built to do some stuff a bit differently from the way you're working.

- Your disassociation between story points and time is something Jira is very happy with - I keep coming back to https://confluence.atlassian.com/jirasoftwareserver/estimate-in-story-points-938845204.html to explain it in Jira terms.  The story points help a team plan and report on commitment, but it's rare that we see two different people log the same amount of time against two stories of the same size.

- There is nothing wrong with your process flow either.  If you're going to use sprints, the only thing you need to worry about there is the "definition of done" - where you burn down on the last column on the board in Jira.  That's done on the story points though, in the model I ascribe to Jira's expectation.

- I'd be looking to the time estimates (if you've done them) and logged work.  It's not unusual to see a sprint planned with Story Points as the estimate, with work being logged in hours, and to help with progress evaluation, the assignees putting time estimates on when it's allocated to them.  The other day, we took a 2SP issue and needed to talk about who would do it - my associate estimated 7 days for them to write it from scratch, my mid-level consultant 4 days to do it from scratch, I went for 2 to do it from scratch, and my principal said 1 hour, because they already have scripts that could do it.  Still 2 SP.

The point here is that the burndown was done on what the team estimated - the SP.  And it was not delivered until it was "done".  None of which stopped us putting time estimates on it and judging in-sprint progress from that.  The time-tracking handled "set it to zero" because the field works that way.  The estimates on story points didn't zero, because they don't need to, you want to retain the estimate and flag it done by status rather than the effort put in.  (Basically "is it done?")

Peter Audooren · Answer

Thanks for the clarification. Then I think we decided to use Jira in an "inproper" manner. Here's what we would like to achieve. How should we change our way of using Jira then?

- We estimate workload in story points, so as to be independent of team member experience: it is only the speed with wich the team member deliveres the issue that will vary.
At this point, we do not estimate time: this depends on who will take the issue.

- In the beginning, we had the 3 default columns on the sprint board: to do, ongoing, done. meanwhile the team wished to have 2 additional columns: "ready for validation", corresponding with "all IT testing completed succesfully for the issue, time for the requestor to step in and do business validation". Once validation is completed succesfullt, move to "ready for release": the entire completed sprint scope is released in production at the end.

- We also want to track progress as tasks near completion.

What is the recommended approach, given the above then?

Thanks. Peter

Nic Brough -Adaptavist- · Answer

No, that's very very not how sprint estimates work.

Have a look at how the time estimates work in Jira - you start with an original estimate, which then does not change (same as story points).  As people log work (giving you time worked), the remaining estimate drops as more work gets done.

With Sprint estimates, you estimate before the sprint, draw items into the sprint, and then mark things as done.

Burn down happens on "done".  If you destroy the estimate, you can't burn down.

When you look at how you progressed during the sprint, one thing you should be looking at is broadly how correct your estimates were.  (Again, you can't do this if you destroy them).  You're looking at how to improve them so that you are better equipped to size your sprint correctly and commit to the right amount of output.

Tracking progress during the sprint is usually done with burn down.  An item is either done, or not.  You burn down when it's done.