“Stop starting and start finishing.” You may have heard this phrase if you’ve been around Agile and Scrum practitioners for a while, but what does it mean? It’s actually a very important philosophy that maturing Scrum teams should be following to help them be more successful at delivering value every sprint.

First, Some Background

If you followed the guidelines for Scrum when you built your delivery team, you will generally have several kinds of members – UI, middle tier, back-end, database, test, etc. – on your team. What I see a lot of Scrum teams do, though, is work with the Product Owner to create stories that break down those stories in layers (UI, middle-tier, etc) and then each developer works on their one or two stories.

Ideally, your stories are vertical slices (I’ll write that up in a future post) that cover all the different elements of the system that have to be written. Many teams are incredibly resistant to this because, honestly, it can be very hard to do. Old habits are hard to break and this is one of those areas where those old habits run deep.

What happens, then, is that individual developers become responsible for individual stories and then work to try to complete those each sprint. What happens frequently is that they get most of the functionality done and then you have to split the story and continue some of the work into the next sprint. The Pareto Principle begins to apply itself to these small stories (also called the “80/20 rule”). If you have this kind of issue, your cumulative flow diagram would look something like the picture on the right. Orange is “defined” (but not active), yellow is “in progress”, blue is “completed”, and green is “accepted”.

Addressing the Problem

How do we resolve this issue? There are a couple of approaches that I recommend. First, is make sure that your stories are in vertical slices, engaging every level of development in every story (if possible). That way you avoid developing in silos that prevent team members from helping one another (swarming, pair programming, cooperative programming, etc.). If you still find your developers working in silos, though, the way to address that is to adopt the principle of “stop starting and start finishing“.

This guiding principle is to push your team to stop working on every single story at the beginning of the sprint and rather working on the top priority items in the sprint backlog (you are prioritizing your sprint backlog the same way you do your product backlog, right?). Focus on working those top stories and completing them before starting on the lower priority items. This is called limiting your WIP (or Work in Progress) and is a key element in Kanban and other lean processes. It helps the team focus on completing the important work, ensuring that the team will actually deliver some value every sprint.

What About Specialists?

This philosophy may require that some middle-tier folks work with database developers or UI developers work with middle-tier, but it does ensure that everyone begins to develop a proficiency with the entire code base, not just their own. This was a key element of Kent Beck’s eXtreme Programming methodology and ensured that in the “proverbial bus scenario” that someone would be able to pick up that work without a major reduction in productivity. It can sometimes be difficult to convince your team to try this kind of methodology but the payoff is high.

Get ‘Er Done

If you can get your team to focus on completing work by limiting their work in progress, you might begin to see some cumulative flow diagrams that look the one on the left (again,orange is “defined” (but not active), yellow is “in progress”, blue is “completed”, and green is “accepted”.). This shows a team starting stories, completing them, and moving to the next set of stories. They’ve limited their WIP and they are going to deliver at least some value by the end of the sprint. There might still be some stories that don’t get completed (as in the sprint shown), but at least some stories are done and accepted. And your team has transitioned over. Stop starting and start finishing – a great guiding principle for teams struggling to meet sprint commitments.