Track actual story points spent on a story (vs estimate) in JIRA

[Slake]

Hi,

I'm kind of new to Jira and I'm not really happy with the way it works in my team. 

Basically during planning we estimate every story (but nobody is assigned to it), devs pick up stories as they  go during the sprint, and at the end of the sprint I have a burndown chart (usually 70/80% of the sprint is completed).

We use SP (story points) as days. When my sprint is 80% completed, I cannot see what caused it. I'd like to have the devs log how many day they actually spent on the story (to be able to compare with the estimate) and the reason why it took longer than expected. 

Is there any way to log this please? 

Thanks

[Nic Brough -Adaptavist-]

Ok, there's two problems here.

Story points are not estimates used for tracking anything outside the team's sprint.  There is no "actual" vs "estimated", it's the same number.  The sprint estimate is for measuring what you commit to vs what is delivered, not "actual".  In fact, Story Points are also there to tell you that your "70%/80% of the sprint is complete" is a going wrong - either you are underestimating your items, or you are committing to too much in the sprint.  You should be moving that to 100% over time.

"We use SP (story points) as days". - nope, don't do that either, Story points are for estimating the relative size of stories against each other, they're never units of time.   There is nothing wrong with doing it days instead, but don't use story points to hold the days, it's confusing for people who are used to using Story points for relative estimation.

[Wenda McMahan]

Thank you! So refreshing with all the incorrect understanding of sprints!

[Nic Brough -Adaptavist-]

It's mostly not misunderstanding sprints here, it's misunderstanding estimates.  But that does break Agile processes when you don't get estimates. 

Scrum and Kanban are older than Agile, but are good processes to adopt when you do want to deliver something useful now, rather than what you (rightly) thought might be useful a few years ago.

One of my little bugbears is seeing people accumulate estimate upwards.  Do you really have 40 development teams all doing their estimates exactly the same way?

[Slake]

Thank you for your answers both :)

@Nic Brough -Adaptavist- Sorry I'm definitely not a scrum expert (as you probably guessed by my first message) and I'm still a bit confused. 

"There is no "actual" vs "estimated", it's the same number.  The sprint estimate is for measuring what you commit to vs what is delivered,"

A sprint is defined in days. How can you not use days to decide what you commit to? Any other value will have to be translated into days at some point, to know if it fits in your sprint, no?

"Story points are for estimating the relative size of stories against each other, they're never units of time. "

Same comment here, how do you define size if not in days? I know not all devs have the same velocity, but we kind of use values for an "average dev".  And days still work as a relative comparison between stories.

If we put the strict scrum methodology aside (and I hope I'm not offending anyone by saying that), if everyone in the team agrees to speak in terms of days, there shouldn't be any confusion. For every story the question is simple: "if you start today on it, full time, in how many days will this be fixed/lived/done". 

@Pramodh M What is it that you call "Original Estimate" ? I don't see it in my Jira settings. 

Would you mind sharing how you would track an example like this ?

Monday 8am, sprint is starting, your dev starts working on a feature and he told you it would take 3 days to complete (let's assume no QA). So in my sprint I have 3 SP (maybe you don't use days and you write 2SP or 4SP based on how you estimate but it doesn't change anything).

3 days later, the feature is not live. The dev didn't really see the complexity of some of the repos they had to deal with. 

The feature is finally live the week after, on Friday, just before closing your sprint. So your burndown chart will show 3SP done. But of course you haven't finished all your scope, because what should have taken 30-40% of your dev time has taken 100% of the time. 

This I can see at sprint level, by looking at my incomplete burndown chart. But how can I get this info at a story level ? Basically to identify clearly what delayed us? (without me manually tracking that in our daily calls of course). 

Thanks again for the help, super nice to see there is an active community on the product :)  

[Nic Brough -Adaptavist-]

"There is no "actual" vs "estimated", it's the same number.  The sprint estimate is for measuring what you commit to vs what is delivered,"

>A sprint is defined in days.

No, they aren't.  A sprint is a timebox with a start and end.  Most people talk about them in days, but the actual unit you use isn't important.  When introduced to Scrum, you'll be told "2 weeks is typical, and a good starting point if you're unfamiliar", but I've currently got clients with sprints ranging from 3-4 days through to 8 weeks.  The 3-4 day sprints are measured in hours.

>How can you not use days to decide what you commit to? Any other value will have to be translated into days at some point, to know if it fits in your sprint, no?

Nope.  Ask it the other way around - why limit yourself to using days when they're often not that useful a measure?  Why not effort (which isn't days, or any other time measure - I can make X amount of effort at a light pace over 24 hours, or I could make X amount of effort and really concentrate on it over 4 hours.  Same effort, different time).  Or complexity?  Or business value?

All valid measures of delivery.

Hours or days are also perfectly valid, but they absolutely are not the only way to do it.  Most teams need something else.  Time works fine for some.  Depends on the nature of the work.

Story points are a technique focussed on relative sizes of stories.  Let's imagine you pick up a story and say "that's a middling complex story, I can do that easily inside a sprint".  Now, how big are all the other stories on the pile compared to it?  Remember - not time or effort, just a broad relative size (if you want to understand why we're not looking at time or effort, imagine you give me two stories - one needs me to code something, and the other needs me to get a load of other people from other teams to gather stuff together.  The first is more effort, but will be delivered more quickly than the second, in less time - that's why you tend not to estimate in time)

[Pramodh M]

@Slake 

Welcome to the community 🙂

Story points is used to track the estimated effort of work and it's either complete or not complete depending on the resolution you set on the corresponding issue.

Original estimate is used to track the estimate of how much time it is going to take to complete the issue

If you track the same value you are doing for story points to original estimate field.

Include the transition screen and time tracking field to track the work log, you will get the logs

Thanks,

Pramodh