Ever changing, never ending

Posted: April 22, 2014 in Scrum
Tags: , ,

I recently read the following article (which I am assuming was written within a Scrum context). Basically, it builds a case for a Product Owner to add more scope to an agreed sprint. It warns that this does frustrate the team and potentially impacts quality, however says it can still be done with the correct amount of justification. The basic agile principle that it bases this on is “Responding to Change over Following a Plan”.

This doesn’t sit well with me at all.

Messing with agreed stories once a sprint has started should be the exception and not the rule. It is very disruptive and de-motivating. Scrum uses time-boxes to limit work in progress and ensure team flow and sustainability (all lean concepts). Continuously changing sprint scope means it’s harder to complete stories to deliver working software. Scrum says that if you need to change the scope of the sprint, you should cancel the sprint. That means stop working, review the stories that are done, have a retro (after all, we need to understand how to improve so that we can avoid cancelling a sprint again), clear the task board, and plan and start a new sprint. It’s a significant event so the process around it should recognise that significance.

My preferred tool for managing change vs plan in sprint is a sprint goal. Agreeing an overarching sprint goal empowers the team to tweak sprint content (with Product Owner input) where it makes sense in terms of the overall goal for the sprint. If new stories arrive that are not aligned to the goal then either the Product Owner must wait for a new sprint to start or acknowledge that the sprint goal is no longer valid (and cancel the sprint). If your goals/requirements change often, consider shortening your sprint lengths. If they change so often that it is impossible to plan a week in advance, then perhaps a more Kanban-like approach will be better suited.

For me, changing stories mid-Sprint when you’re running Scrum points to a deeper issue, and merely substituting/adding stories addresses a symptom rather than dealing with the cause. There would be a number of ways to address that cause (sometimes it’s merely a case of educating the business or learning to say ‘not yet’). The important thing is to ensure everyone is aware that this is a big deal and help the team find the best way to deal with it in a way that ensures all agile principles are satisfied.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s