Using Jira with Story points - couple of questions

[Peter Audooren]

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

[Peter Audooren]

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-]

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?")

[Nic Brough -Adaptavist-]

>when dragging an issue on the Kanban board to the "Done" column, remaining story points are not set to 0.

No, they're not supposed to be.  That's not how estimates work.  If you set your estimate to zero, that destroys the point of estimation and all the reporting you can do on it.  The only time you set a story point estimate to zero is when you decide to cancel it or work out it needs no work, before you draw it inot a sprint.

>If doable, how can we achieve this?

A post-function on the "close" transition would destroy your estimates for you

>The Kanban board shows remaining time instead of remaining story points.

Yes, that's correct.  Kanban does not use story point estimates, so Jira shows you the time-tracking on it.  (Actually Kanban does do something like Story Points, and if you wanted to oversimplify it, then a very simple description is that one card = one story point)

I think you need to go back and look at how you are doing estimates.  Why are you thinking you want to set the story points to zero?

[Peter Audooren]

Before the sprint starts, workload is estimated. We're using a Fibonacci series for story points. During sprint, we want to track progress. So, I am under the assumption that that should be done by adapting the story points to whatever quantity of work remains to be done, hence 0 when the issue is done.

The burn-down chart of story points allows tracking progress.

Maybe Jira intends working in a different way/process/flow? What should it be then?

Eventually what is important:

- ensuring that the team makes a realistic commitment at the start of every 4-week sprint

- tracking progress during the sprint, including knowing where items are (to-do , in progress, done)

All recommendations welcome.

[Nic Brough -Adaptavist-]

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.

[KAGITHALA BABU ANVESH]

Hi @Peter Audooren ,

Story points estimation is done for Scrum projects.

story point estimation is not available for Kanban Project templates. as we check in board settings, The estimation is missed in Kanban,