A Backlog for Ruthless Prioritizing

So far, I’ve talked about how I went for Introducing agile practices to manage a remote development team as well as User Stories – Making Sure Your Customers Get The First-class Seats. While User Stories are a good start, enforcing ruthless prioritization of these stories can really streamline your development processes.

Priorities get mixed up when you’re doing to many things in parallel

One of the worst things about dealing with too many issues at once is that every one of them seems to be the most important one when you’re looking at it by itself. The reason for such misjudgment is that while you discuss one issue via chat, phone or email, you often don’t see the whole picture. Before you know it, you’re constantly changing priorities and generating a lot of context switching in development.

Starting more work does not lead to faster results – on the contrary!

If you keep talking constantly about all your issues, you tend to think that everything is being worked on in parallel even if you have only one developer. So your expectations rise to unrealistic levels and you tend to push harder (often to the misfortune of both product quality and your team’s morale).

Making Real Capacity Visible by Serializing Work

To establish a shared, more stable understanding of priorities and a better perception of how much work can be done, my second agile process change was to force all User Stories into one list and sort that list by priority. I did not allow two items to have the same priority as our organization didn’t have the capacity to do things in parallel. That forced us to serialize the things we had been working on which, when paired with rough estimations of all issues, gave us a better feel for the amount of work to be done. Our Backlog was born.

This was a really hard exercise because suddenly it became very apparent that not everything could be worked on right now and not everything would be done by the end of the week. Discussing each item in isolation created the illusion that everything being worked on would soon be finished. When Friday rolled around, it was pretty disappointing to realize we hadn’t really accomplished anything.

Breaking big feature sets into comparable chunks and forcing people to order them by priority was an eye opener for my team. We managed to focus on the most important things first and I enforced the rule that nothing new gets started until the current User Story was finished. Again, this was tough. There was the typical perception of “committed is done” which I had experienced all too often in the past. But I didn’t waiver. I insisted that the product owner hold all new requests until the current stories were done and I ensured the developers really finished a Story before accepting new ones.

In the long run, this approach even led to faster development as everyone was able to focus and we minimized having to re-work features.

Transparency isn’t always welcome – but you can’t improve without it

Did I already mention that this was hard 😉 ? It’s always hard if you take away the dreams of people by making problems visible and not being able to offer immediate short term solutions. It’s so much easier to ignore the problems and blame someone else for not delivering either “perfect specs” or “perfect code”. But the pain is definitely worth it once everyone sees quality and speed increasing after a perceived slow down. Perceived because actually there usually is no real slow down. If you were paying attention, you’d know you weren’t so fast in the first place. The feeling of higher speed was only built on the impression that you were constantly driving everthing instead of only one thing. Serialization of issues and concentrating on really finishing stuff are the keys to higher quality and higher output.