How to recover Story Points when Issue goes into/past certain Workflow stages

[Nathan Pledger]

Hi,

We'd like to be able to differentiate a Developer's work "done" vs. actual done-ness. We have workflow similar to:

To do > In progress > Dev Test > UAT > Done

Where:

• Moving into UAT marks an Issue "Done" for the developer
• Any remaining Issues on the board at time of Sprint completion get rolled over into their same positions in the next sprint
• UAT and Done are both marked as "Done" in the Workflow designer. This is reflected in their boxes appearing green and the lozenges for those states also being green.
• The Resolution Status is set to "Fixed" when moving from In Progress > Dev Test
• Dev Test to UAT marks the point at which we deliver into UAT which can occur multiple times per Sprint.

How can we mark the Story Points as being "Done" (and therefore released) when Issues move from Dev Test to UAT?

Thanks

Nathan

[Nic Brough -Adaptavist- · Accepted solution]

I think you may be in a place where you have no clear consistent "definition of done", which generally will not work.  But there are a couple of odd things in your bullet points which are unclear to me and I'd like to question:

I am going to assume you have one board that the developers are using to run their sprints.  Given that:

• Moving into UAT marks an Issue "Done" for the developer
  • So both your UAT and Done status in the workflow are in the last column on the board?
• Any remaining Issues on the board at time of Sprint completion get rolled over into their same positions in the next sprint
  • Ok, no question from me
• UAT and Done are both marked as "Done" in the Workflow designer. This is reflected in their boxes appearing green and the lozenges for those states also being green.
  • Ok, no question (but I wanted to say the "jira speak" for this is "status category"
• The Resolution Status is set to "Fixed" when moving from In Progress > Dev Test
  • Resolution Status is not a thing in Jira.  It's a horribly confusing thing to say when talking about Jira because Resolution and Status are two totally different things with no technical relationship at all.  Do you mean Resolution or Status?  I am 99% certain you mean Resolution this time, given the rest of the question, but can you confirm this?
• Dev Test to UAT marks the point at which we deliver into UAT which can occur multiple times per Sprint.
  • Makes sense, but I have a question - you've given us a linear workflow, from which I usually assume there is a bit more to it.  If you can go Dev Test -> UAT multiple times, I assume you have a transition back from UAT to somewhere?  Do you re-open issues that fail a test, or do you create new issues (or sub-tasks) as defects? Do those go back through the whole cycle from to-do with these?

My first question is the most important one - the column definitions.  The later ones are clarifications, but their answers could be very useful in defining an answer.

[Nathan Pledger]

Thanks Nic. Your response is both timely and informative.

To answer your questions:

• Within our team, we want "Done" to mean when the Developer is happy. We're seeing bottlenecks in UAT which is impacting our velocity figures. 
• UAT and Done are separate states. States being:
  To do > In progress > Dev Test > UAT > Done
• I do mean Resolution, and yes, confusing! Sorry for that!
• Yes, we do have reverse/regression routes from UAT back to In Progress if a Test was to fail. I feel we might have found a hole in our process, if we've "released" the Story Points with Dev Test > UAT, regressing that back to In Progress should add them back. Not sure if this is a thing.

Our ultimate objective is to be able to say to our Development Team Lead (me/my manager) "we've done this much work this Sprint" and not be held back by (understandably) less Agile parts of the business. We need to respect that whilst we're Agile, we aren't necessarily surrounded by Agile - well, not yet, anyway!

[Nic Brough -Adaptavist-]

Ok, great.   Well, the only way to have a developer consider UAT done is to have UAT and Done in the Done column.

This looks confusing from the outside of the development team, but they're in a position where they can state that this definition of done is absolutely correct.

I would then use a Kanban board, with the same filter as the developer Scrum board, but with separate UAT and Done columns for the UAT people to track.

This will make your Scrum board give you the right reporting most of the time.

But as your UAT is outside, I would probably want to look at how it feeds back into your development cycle. 

Re-opening a specific story is one way to do it, but it does feel unfair because your developers genuinely thought it was done, but had it rejected by someone/something outside the control of the team which causes your work to stop counting as "done".  Ideally, the testing should be part of the Scrum, so "done" really is just "done", but I know that doesn't happen.

I usually recommend that defects are raised separately in these cases.  Ideally as a new story that you will take into the earliest sprint you can, you don't re-open something you've delivered.  If you're going to do that, then the developers should accept that all defects automatically outrank everything else in the backlog, so when you're building the next sprint, all of them go in.  Your testers will have to accept that any defect raised will not be looked at until the next sprint starts.

This has some advantages - mostly, your Scrum team will start this with something like "assume 20% of our story points are going to come from the defects from the last sprint/delivery".  You'll be able to refine that as you gather data from knowing how much you spend on real work and how much you spend on defects.  It has a big benefit in measuring quality - if you can see story points on defects rising, with less and less development happening in a sprint, you can see you have a code quality problem - developers are turning out buggy stuff they need to fix later - you'll never get to 0% defects, but you should be aiming for it. 

A bit more thought about reporting on it can also show you how well the testers are doing, even though you're not directly measuring them, and it can show that they might be a bottleneck, and maybe it's time to build multi-functional self-directed teams so you can incorporate testing and have a proper "done means done" approach...

[Nathan Pledger]

Thanks Nic. Your pragmatic appreciation of the role of Agile in reality is appreciated.

I was feeling two Kanbans (one for Devs, one for Testers) is what would be required, and that defects should be raised in their own right, but it does feel incomplete in terms of SDLC. 

Unfortunately we can't have the luxury of controlling inputs into our Sprints, we're mostly accounting for the quantity of the work we're doing at the moment within a busy environment. So asking users to wait until the next Sprint would be meaningless and possible offensive! We'd need to absorb them and allocate a percentage per Sprint for inevitable creep.