Ending a sprint with linked sub-tasks

[David Hazeel]

Hi,

I've read a few other questions that skirt around around this issue, but can't find an answer to my specific query. I'm using Jira Cloud and a sprint board.

I have a story, A, that has two subtasks, x and y, that use the 'relates to' link.

If I pull A, x and y into a sprint but only x is moved to done, what will happen when I end the sprint?

If I move incomplete tasks into a new sprint, will A, x and y all be pulled into the new sprint or will only A and y be pulled in?

If all 3 tickets will get pulled into the new sprint, is there a way of still using a link between the tickets for reference that will enable only A and y to be pulled into the new sprint? Or would this only be possible if there were no links (so I would have to reference the 'link' in a comment or in the ticket description - I'd like to avoid this sort of bodge!)?

The team I am currently working in does a lot of content work where often only parts of a story are possible during a sprint, for various reasons. We'd like to have a scenario where we are still able to claim points from a sprint so that we can effectively use a burndown and not have lots of tickets clogging up the board. For example A might be an 8 point story, with x worth 5 points and y worth 3. We'd like to 'claim' the 5 points for x without the whole story being done.

Thanks in advance.

[Nic Brough -Adaptavist- · Accepted solution]

Sub-tasks are essentially irrelevant in scrum.  You plan stories (or at least at the level of story) and in a sprint you commit to delivering a set of stories.

If you choose to break up those stories internally with sub-tasks, that's fine, but your scrum planning is done on the stories.

The sub-tasks simply move with their stories because they are part of them

This clause jumps out to me:

>only parts of a story are possible during a sprint

That means you're not doing scrum "properly".  If a story is too large to fit in a sprint, it should be broken up into smaller pieces that do fit. 

Links are similarly unrelated, but not because of the nature of scrum, it's because they're links.  A link tells humans and Jira that "these two issues have a relationship the users need to be aware of", but nothing more.  The issues remain separate issues with their own data which is independent of the issues at the other end of any links.

[David Hazeel]

Thank you. We definitely aren't doing scrum 'properly' with our work - which is a conscious choice as we have found a halfway house that works for what we do. That we can split a story down and have it go across sprints is very helpful in our instance.

[Nic Brough -Adaptavist-]

Yep, a lot of us don't do it "properly".  When we don't, we run into problems with tools that are built to support doing it properly, and often don't have functions for our way of doing it.

Jira is one of those tools.  It's a lot more flexible than many of its competitors, but it's  still built for "real" scrum, which only gives you credit for "completely done" at the time you finish the whole story.

[Ryan Fish]

@David Hazeel

Sizing and splitting stories will help your team communicate, build a better burndown, and increase throughput. The dev team should have a Definition of done and all the skills to meets the DoD.

Several questions to start the conversation in sprint planning are:

• How can we deliver story ABC?
• How can we satisfy the definition of done for story ABC?
• How can we make story ABC smaller/ Is story ABC the correct size?
• etc...

Things to consider in your sprint journey

• How is the team talking through impediments before they happen in Sprint planning and daily scrums?
• Are they reviewing said impediments in Retrospective and planning how they can mitigate, avoid, or eliminate?
• What root causes are outside of the teams control and how can the Scrum master improve the odds of not having the impediments restrict development?
• etc