Marking tasks as done on different stages of the board

[Martina Moring]

Hi all, hope someone can help with this.

We have our board set up with 5 stages, to do / in process / ready to deploy (beta) / ready for review / done.

In order to properly measure our dev teams' burndown, we would need to have issues marked as done once they reach ready to deploy (beta). Issues usually have a waiting time on that stage, until a bunch of them are deployed together. Then our product manager reviews them, and they go back to to do if there are changes to be made or to done when they are good to deploy into production.

So if we use done to mark an issue as completed our teams burndown will be influenced by the task of the product manager, and by the time tasks are waiting just to be deployed.

I've configured our board like this, but still can't get issues to be marked as done when they reach ready to deploy. 

Although there are 9 tasks done in ready to deploy (we can see them crossed out and marked as done on the board) the burndown chart doesn't recognize them, we still have all the story points from the sprint as remaining.

Any help on how to get this properly configured would be amazing!

Thanks,

[Fernando Eugênio da Silva]

@Martina Moring 

Burndown visualizes when the issue arrived in her "Resolution".

For this to work as you expect, you need to do the following:

In the flow, check if only for the status "ready to deploy (beta)" there is a post function indicating the resolution of the item. And for the other statuses of "ready for review" and "Done" there is no post function indicating item resolution.

Something like: In the transition of the flow that leads to ready to deploy (beta), click on post functions
Then click on "Update field value", search for the "Resolution" field and enter a value of type "Done".

Validate if in other statuses this behavior is not repeated to ensure that only one status has recognition of item resolution for burndown.

So your issues can move between the later statuses of ready for review and Done without losing the value of the resolution field filled in before and even if a burndown is generated in the issues that are in any of these 3 statuses, they should go to the report because already have a value of "Resolution" filled in.

Also, keep this "Set Resolution" tag only in the "ready to deploy (beta)" column and not in the others, so that the field value is filled only in one issue stage.

Now the value of "Resolution" needs to be changed between these last 3 statuses, I'm not sure how burndown behaves with too many changes.

But it's a path we can explore.

[Martina Moring]

Hi Fernando, thanks for your answer!

I tried removing the set resolution from the status "ready for review" and "done", but this only achieves removing the done status from the issue when it is moved to any of these columns.

The burndown still doesn't reflect any of those changes. Do you know what affects the burndown? Is it the resolution, the status, the column done? I can't figure what it is exactly to be able to replicate it on the ready to deploy (beta) stage.

I'm not sure how to adjust post functions. We are using the simplified workflow, 

Thanks,

[Fernando Eugênio da Silva]

@Martina Moring 

Burndown is affected when the issue meets the value "Resolution", this is the data factor for burndown.

We usually have more access with burndown and this data view when we've completed a sprint.

So I would recommend that if you can create a sprint ghost just to indicate some test issues and fill in the resolution to generate burndown.

About adjusting the post functions, review the following:

Open the flow and click on the transition that will take you to the desired status, then select the "Post functions" option.

A new screen will open and you will need to click "Add post function".

After clicking on "Add post function" search and select the option "Update issue field".

After that, select the field "Resolution" and mark a resolution, in this example it was "Done".

Click ADD and publish the workflow draft.

Check the other transitions to see if there are solving post functions filled in, and remove them.

I recommend creating a copy of this current stream, as you might need to make some other changes and you may be able to resume the previously used stream if you don't see any progress in the results ;)

[Martina Moring]

Thank you! I've adjusted the post functions, and double-checked that only the transition from "in progress" to "ready to deploy (beta)" is the one that changes the resolution to done.

All other transitions won't affect the resolution, unless the issue goes back to "to do".

I created a mock sprint to see if this works. I'll update progress tomorrow, hopefully, it will update the burndown properly. I will let you know.

Thanks!

[Martina Moring]

@Fernando Eugênio da Silva Unfortunately, this doesn't seem to work. Here's our burndown chart

It doesn't register the resolutions, although items have been moved to the ready to deploy (beta) stage. And gone through the transition correctly (you can see the resolution change in history).

Here's our workflow just in case. As you recommended the only transition that affects the resolution is the one from 'in progress' to 'ready to deploy (beta)'. The resolution seems to be working fine as the history of the issue shows. However, this doesn't impact the burndown chart.

Is there any setting on the burndown we should change?

I tried moving the issue to 'done', and that does affect the burndown chart. It is the only stage that affects the burndown since issues are marked as completed. However, I couldn't find a specific function that does this. The 'done' stage doesn't have any specific properties, and the transition doesn't seem to affect that either.

Sorry for the long post, but I can't understand what is marking the task as completed. And how to move that into the 'ready to deploy (beta)' and I want to give you as much context as I can.

Thanks,