locking stories and features for a sprint

When the stakeholders have completed prioritisation of stories and assigned them to a sprint, and the team has agreed that the sprint is achievable, how is or how can the sprint be "locked down" so that stakeholders can't sneak in new stories to an in-progress sprint?

I imagine this is doable with permissions (e.g. not giving out Schedule Issues permission) but that prevents stakeholders prioritising all the time, including during sprint planning. Of course there is always the possibility that a critical bug will emerge requiring priority implementation without a full sprint restart, so it should be possible to update an in-progress sprint, but under the control of the Scrum Master.

Have I missed something in GreenHopper, or are permissions the only (system) way?

Thanks

3 answers

1 accepted

This widget could not be displayed.

Greenhopper honours the underlying Jira workflow and permission scheme. It does not have any additional features around this area.

So will need to find a solution there or look to bespoke development, i'm afraid.

However, if you base the prioirtising phase on the planning board, by using the ranking field and markers, then should be able to remove the permission from the stakeholders without impact. Once the prioitising is done the 'responsible' person can drag and drop the top x issues as shown by the markers into the sprint. It just becomes a single action that the stakeholders do not need to do.

Obviously the above is very simple, and has no knowledge of your process, setup or working culture so may simply not be feasible for you. But if you use constraints and are running daily sprints you should be able to effectivley police this as would be very visible if more issues started showing up.

Thanks Martin. You're right, there definitely would be indicators on burndowns etc that would give it away, and solid process would keep everyone honest. Just checking that I hadn't missed some obscure system function, and you've answered that for me, thank you.

This widget could not be displayed.

I use a SQL query to scan JIRA's change history. If issues have their versions changed to the sprint I've locked, then I'll see it in my report.

This widget could not be displayed.

I may have found a potential work around for that..

1. You can create a new status, called 'Ready for Sprint'. So in your Scrum board, on your "To Do" you will be display these.

2. When you create your sprint, your PO will have to change the status of all the stories to be 'Ready for Sprint' so they will show in the board.

3. Last bit is to restrict that only your PO can move a story into 'Ready for Sprint'. Anyone can move a story to 'In Progress' as long as that story has a current status of 'Ready for Sprint'.

Does it make sense?

 

 

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted 7 hours ago in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

13 views 0 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you