Using Scrum effectively is more than just holding Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. As agile coaches are prone to say (and we agree), Scrum is a good start, but it’s not enough. Just doing the forms (“sure, we hold Sprint Planning events…”) isn’t going to make the difference.

If you really want to see a big difference in the amount of work that your team can do in a Sprint, there are a couple things you can do. In this blog post, we’re going to stuck with the workflow-based changes you will want to make and not get mired in the technical stuff you could also do. Why? Well, here’s the reality — if you focus on technical solutions to performance without addressing the fundamental workflow issues first, you’ll end up with a beautifully constructed product that will still take 10x more time and money than it needed to.

We’ll deal with the technical stuff later. Let’s get the fundamentals right first. Good news! There’s only three!

1. Avoid Technical Debt – Your team needs a DONEness definition that 1) they keep up to date and improve every chance they get and 2) they actually use! DONEness is not about being perfect – we’re human and teams will make mistakes. But a lot of those mistakes can be found before the Sprint ever ends if only we would pay attention while the work was being done.

2. Work Only on Small Backlog Items – The bigger the product backlog item, the greater the complexity, the greater the risk, the greater the cost. Unfortunately, building a software product is not the same as building, for example, a car. Building two cars will, by and large, cost you twice as much as building one car. Building a product backlog item that seems to be twice as complex will likely cost you 5-10x what the simpler item cost. It’s not a linear progression, it’s closer to an exponential progression. So, to reduce errors, work only on small backlog items.

3. Work Only on One or Two Backlog Items at a Time – In other words, keep your work in process low. The more backlog items your team has in progress at the same time, the more chance that team members will be interrupted to help other team members, causing context switching and loss of productivity. Doing more at the same time doesn’t get more done — it gets less done.

So, that’s the plan. If you REALLY want to be Agile, you’ve got to make some changes to how your teams do work. Just calling it a Sprint doesn’t make things better. Get a good DONEness definition in place and don’t compromise it. Work only on small backlog items and, even then, only on one or two at a time to reduce unnecessary overhead. Give it a shot!

If you have difficulties with these concepts or just have some questions, please feel free to contact us!

FEATURED RESOURCE:

FEATURED RESOURCE:

Guide to Defining DONEness

Download Now!

Swipe this FREE DOWNLOAD and define your quality outcomes.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #Productivity

Gearing a Team for Maximum Outcomes

Creating a maximum outcome team is every ScrumMaster’s goal, but you must first understand how great teams form and what YOU need to do to create a great team.

Simplify Your Work by Slicing

When slicing a backlog item, we're taking a complex problem and paring it down into smaller problems, which are easier to solve and build.

5 Ways to DOUBLE Team Performance

Here's 5 steps you can take as a manager or ScrumMaster to help DOUBLE your Development Team's performance (#5 is a shocker; it's easy but SUPER non-intuitive!)