Is our sprint length wrong?

Tagged: agile scrum sprint jira

A little while back, I fell into the role as scrum master as well as developer on our team. I think partly because I was experienced enough and not yet universally hated. Having not done this role before I was sent to do some scrum training (very interesting by the way, I would highly recommend it for those ‘doing agile’ https://www.agil8.com/our-team/david-hicks/)

One of the common themes in the training seemed to go against how the team had been traditionally run. Doing things as late as is sensible to do so and only work on what you know is wanted or delivers value.

It sounds counter intuitive but the more unstable the clients requirements are the later you should do grooming / refinement in the sprint process and also the length of the sprint should be shorter.

One thing that we had to do as team is to change our attitude to sprints. We fell into the trap of using the sprint as a safety net where an indecisive client had limited scope to bother the development team for a few weeks. The danger here is you try to lengthen the sprint as it seems easier / nicer to have set work and not have things change.

Currently we’ve started doing things as late as possible and we’re finding there is much less change between refinement and sprint planning, though we’re still finding there are interruptions to the sprint where things ‘just have to be done.’

Here is our latest burndown chart, it’s pretty typical for our team, not perfect as we’re a large team (over 10) working on the two biggest websites for our largest client, carrying out a mix of BAU and project work in the same sprint, with a lot of legacy bugs to resolve.

It Doesn’t look so bad but something is a lot clearer when you view it with the non-working days shown.

We immediately noticed that all of our sprints followed the same pattern, that most of the scope creep and changes happened in the second week. At the minute it isn’t feasible to work to a shorter sprint length as we’re tied to the same release cycle as the rest of the platform, though once we have finished the project to decouple ourselves from the wider platform I’ll be pushing for us to try out shorter sprints.