Stories Closed Outside of Sprint

[Capo Di Tutti]

Hello, 

New poster here! I've gathered a lot of knowledge from browsing the Q&A boards over the last year and I'm happy to see so many knowledgeable professionals sharing their insight and wisdom, so Thank you in advance!

Root Issue:  As Scrum Master I see a re-occurring problem of stories closing outside of  original assigned Sprint.  Example - You planned a Story's closure for Sprint 10 but an analyst was able to close it in Sprint 8 and did not change the Sprint allocation, so its Now closed and still marked as Sprint 10.

Problem it creates:  When Stories close before original allocation (using example above) they do not show up in Sprint 8 retrospective stats. They instead stay in "Closed outside of Sprint" Bucket. The same occurs in Sprint 10 when again it stays in "Closed outside of Sprint" but doesn't seem to count toward the Sprint Retrospective numbers.

How do you folks handle these? What is best practice for being able to show the work was done as far as providing the proper optics to the end client? 

Thanks in advance - Grazie !

[Nic Brough -Adaptavist-]

There's nothing wrong with this. 

In your example, the issue was closed before it went into sprint 10, so it was closed before being counted as part of the sprint.  It was never put into sprint 8, so it was closed outside sprint 8.  

There are two simple ways to handle this

Just ignore them.  The data being reported is accurate and tells you what happened.  You don't want to add the issue to sprint 8 and hence creep the scope of it, that's fine.

Get people to incorporate the scope creep.  This isn't a bad thing, as long as all the other things the team committed to are complete, then by all means, draw more work into the sprint and get a velocity record that you managed to over-achieve.  Use that to improve your estimation and delivery

[Capo Di Tutti]

Thanks for the answer Nic, I follow your thinking here. 

One issue that makes this more problematic than it actually should be is the client and many current users aren't familiar with Jira nor Agile for that matter. Its a building process of course....so I'd be better off explaining the reality of fluctuation and some scope creep in the Agile world, does that sound accurate?

[Nic Brough -Adaptavist-]

>I'd be better off explaining the reality of fluctuation and some scope creep in the Agile world, does that sound accurate?

Very much so, yes!  Your client doesn't need to completely understand how Scrum or Agile work, but having them understand the basics of velocity (it's measuring the team's delivery vs commitment, not progress - that's the thing most people don't grasp at first) and the numbers they're seeing is really very helpful!

[Capo Di Tutti]

Sound advice Nic

Last question then  - Any choice articles you could recommend which might help me better explain delivery vs commitment and not progress as you're saying?

I've worked in Jira for years and ran projects in "Agile-like" environments, but this particular project is larger, with more moving parts and most of the teams involved are new to Agile & Jira folks, so I'm getting questions and concerns I'd never thought of before.

Cheers and you've been a big help Nic!

[Nic Brough -Adaptavist-]

https://www.planview.com/resources/articles/lkdc-velocity-agile/ is a nice plain English write up of it (I find the Scrum organisations tend to write in very Agile jargon laden styles, so you have to understand the jargon before the explanation makes a lot of sense).

It doesn't say "it's not a measure of progress" explicitly, but it does explain what it is for.

The reason it's not a measure of progress is that velocity changes, and is expected too.  The estimates it is based on are also not measures of progress.  If a piece of work is estimated at 4 hours, or 2 story points, the actual completion of it tells you nothing about the progression of the overall project.  To measure that, you would be looking only at what is delivered.