Sprint Benefits

Joe_h48wvb

Hello everybody!

I've finally implemented the transition from Trello to Jira for our Tech team, and I'm already reaping big rewards such as connecting our version control, and finally being able to measure workflows!

One real problem I'm having though is selling the benefits of doing sprints properly. More often than not we're left with the same amount of issues on the board than what we had at the top of the sprint. This is mainly down to the inability to sell the idea that "do less, deliver more" works, ergo huge scope creep, as well as the power gradient between myself and the product owner being pretty steep.

I realise this is a general issue rather than jira specific, but if anybody has any experience I can draw on, I'd be hugely grateful!

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

The biggest benefit from using sprints is that you actually deliver stuff, and you deliver what you said you would.

If your product owner is allowing scope creep, then they are not doing their job properly.

If the "do less, deliver more" message is not working, then maybe shift to "deliver what we said we would" (and I'd be quite blunt with the product owner - tell them that they are a failure as part of the team, and they are failing the organisation/customers to which they are making promises to that they then don't keep)

There are a few other things to look at too.  Scrum is hard to keep to, but needs you to stick to the rules - scope creep should be a rare exception, don't commit to more than your velocity says you can, it doesn't matter how urgent someone thinks a bug or defect  found in the last sprint's output is, it goes into the backlog (right at the top ideally), not the current sprint, and so-on.

In reality, things do happen that will tend to cause scope creep.  Developer asked to look at a possible bug in production, urgent bug appears, security issue found, and so-on.

The best way to deal with these is allow for them, log them, and work out how to handle the constant flow best.

At one end of the scale of things you can do is "allowance".  If your velocity is currently 100, then when planning the sprint, only commit to 80.  Then you've got 20 wiggle-room for incoming stuff.  80 is an arbitrary starting point, I don't know what it might be for you, but you would adjust it, as you do with your real velocity.

At the other, it's actually "Kanban".  Scrum doesn't work if you've got a constant flow of incoming stuff which takes a priority over your committed work.  Kanban does.  The only rule you'll need to enforce is "once we start on a card, we do not pick up another one, no matter how urgent, until the current one is done".  In your case, this would shift all of the problem on to the people who are insisting on scope-creep - your team would be doing what needs doing according to their priorities, let them argue it out.