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

Question

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- · Answer

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?

Wenda McMahan · Answer

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

Nic Brough -Adaptavist- · Answer

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