How to accept stories with CI/CD in JIRA

[Lars Böhnke]

Hey community! I am a PO and for our product we're using JIRA and CI/CD and Scrum. That said, I don't accept a story at the end of the sprint but rather immediately when the story is finished.

We have a DoD which contains several things among fulfilled acceptance criteria. So when a dev things a story is done and it has passed code review and the PR is merged, the story is transitioned to done.

What I'm struggling now with is how to accept the story. In a true Kanban style we're not moving issues back on the Scrum board. So for example if during code review some issues come up which the dev needs to address, the issue stays in the 'In Review' column until that is done.

Would you introduce a new status 'Accepted'? To be honest I would try to not do this but rather keep things simple. However I am clueless how to accept stories and manage the process behind it. During a sprint stories will naturally pile up so it is a bit hard to keep track of stories which I cannot accept (yet). Any ideas? Would appreciate your thoughts!

[Jack Hunter _HeroCoders_]

Hi Lars,

What about using a checklist of DoD attached to the issue and blocking issue resolving if checklist/DoD is not completed?

The completed checklist could play the role of completeness from a development perspective while moving the issue to Done could mean accepting an issue (or the other way around).

Overall, the checklist item is similar to a sub-task but much easier to create, complete, rename, delete, reorder and so on. 

If you think that could work, then please take a look at checklist apps available on the Atlassian Marketplace, e.g., Issue Checklist Free and Issue Checklist Pro delivered by my team. 

If you require anything specific to achieve what you need, then please let us know. There are plenty of features available that can help in many cases. 

Cheers,
Jack

[Erica Moss]

@Jack Hunter _HeroCoders_ Hey, Jack! Just a heads up that we want to keep our responses to questions here super relevant to the topic at hand. In general, we want to avoid being super promotional, per the guidelines for vendors and partners. Thank you!

[Jack Hunter _HeroCoders_]

Thanks @Community Manager. 

I tried to be helpful and relevant but I guess the links are breaking the guidelines?

I will avoid linking the product page if not directly asked.

Cheers,
Jack

[Petter Gonçalves]

Hello Lars,

I hope you are having a nice day.

Analyzing the scenario you described, I believe that a new status would be the most reasonable option to achieve your need.

You could create a new status called Waiting for approval and even add workflow conditions that will only allow the responsible team to accept it.

Another option would be to use sub-tasks to track each step of the Story or use the same hierarchy relation with Epics-Stories. I think this option would better organize and describe the details and tracking of each step in your Stories, however, it would not keep things in the simplest way you want.

A third option would be to create a linked issue to verify all the acceptance Criteria regarding the issue. This would be a good practice to separate the estimated time of the development team from the team which will verify the acceptance Criteria Steps, however, I think it will also fall behind when you talk about simplicity.

Let me know if one of the options above helps you.

[Lars Böhnke]

Hey, thanks for your answer! We just came to the conclusion that each story should have at least one subtask. With that combination we can use swimlanes. Once a story is implemented every subtask is moved to done. If the story is accepted, I move the parent issue to done.

[Petter Gonçalves]

Hey Lars,

The practice you have implemented in the third one I described, although I suggest you to use a Linked issue instead of Sub-tasks since a link type as "Blocked by" would be more understandable in my rumble opinion.

Anyway, I'm glad to know you were able to get a better way to organize your progress. 

Have a nice day!