Set Dev-Done Stories to "Done" for upcoming Sprint

[René Pardon]

Hey there,

i got an organsiation problem if i want to finish a sprint. 

Background:

We are working with a "light" SCRUM version because of the organsiation structure and using the JIRA Boards for the whole project organisation. 

I know, its not the official SCRUM process but all in all it works fine for us. 

But there is one thing we always struggle with: there are multiple tasks which are "Dev-Done" - means they are in the "split" - "Development finished". 

The Problem: these storys are not "done" because the testing and QS is open.

The sprint is over and i want to finish the sprint. If i click the button "finish sprint" the remaining tasks which ARE NOT in the split "done" will stay in the current sprint. 

Till now i always split those tasks with 0 story points and let them take over in the new sprint. So the velocity stays in the current sprint and the "QS" Tasks with 0 story points take over in the new sprint. 

The question now is: is there a possibilty to configure the "finish process" on a way, that the tasks which stay in split "DEV FINISHED" or "QS" will set to "DONE" and will not take over in the next sprint? Because (in most cases) the Dev part is done and the velocity remains in the current sprint.

We use the releaseversions and keywords to make a list over the "open" QS / Testing tasks.  So its ok, that those storys are not in the current sprint.

Thanks for your feedback!

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

No, there's no way to do this.  You can't put issues into a quantum state where they are done and not done at the same time.

What I would do here is admit that you're not remotely doing Scrum (albeit you might still be quite Agile) and split the process because you've effectively got two teams doing the work, rather than a single cross-functional one that Scrum wants, even if your organisational structure defines the people as belonging to one team.

When you have two or more teams, the most effective thing to do is have each team use a different board.  This way, each team can be very scrum-like and you don't need to mess with zero estimates or split ones.

Imagine a simple workflow with the hope that an issue can just go straight through it (going back in the flow and having lots more status, or boards with more than three columns are a diversion here, it's the status and column mapping principles that matter)

New -> In dev -> Dev done -> In test -> Finished

Your test team should have a board that lists columns:

• To-do:  Dev-done
• In-progress: In-test
• Done: Finished

Your dev team is a little more complex, they need

• To-do:  New
• In-progress: In-dev
• Done: Dev-done, In-test, and Finished

The basic idea here is that "one team's 'done' is another team's 'to do'".  This method is not truly scrum, because it has many definitions of done and you don't have teams that can deliver something alone, but it does make your teams pretty close, and gives you all the reporting by team and story that you need.

[René Pardon]

Wow! Didn’t expect an answer like that. Pretty much thanks! 

Yeah. that’s the problem. The organisation says, its “one team” and we try our best to life the scrum process with that people. The problem is the release times which are not connected to the end of our sprints and we always need more time for testing. 

that means, there are always tasks which are dev-done but not tested from QS and ready for deployment. 

i also got the idea of having 2 boards today but wanted to make sure there is no other opportunity to handle with that. 

I guess that will be the way to go then.

thanks a lot. have a great time! 

[Aron Gombas _Midori_]

While I really like what @Nic Brough -Adaptavist- suggested, an alternative could be modeling each problem "X" with two issues in Jira: "Develop X" and "Test X". And define a custom link type "tests" (and "tested by") and create links between those.

That could be very flexible, because the assignee/lifecycle/sprint of the two are detached.

To make more consistent, you could somehow enforce a validation which only allows moving "Test X" to "In progress" when "Dev X" is already in "Done". It requires a validation but sounds like an easy thing to build.