On The Inside: I want it all, I want it all and I want it now!

Welcome back to On The Inside! This is part 3 of my Agile adventure at Allthings, a technology startup in sunny Dundee building a group project collaboration tool. If you haven’t read part 1 (which is all about diving into the deep-end!) then you can find it here (part 2 is here). I’m trying to give an honest, personal, warts-and-all account of our journey…

At Allthings, we needed a plan and a direction for our product, in particular, which features to do next. I started asking around and I kept getting the same answer, “I want it all and I want it now”. I’m paraphrasing, but you get the idea. I’m sure you’ve heard the same answer before. It’s the answer you get when the person answering the question can’t tradeoff the choices you’ve given them.

 productivity-495920-edited

However, at a startup, with a small team and limited time, there just isn’t capacity to start everything we wanted to do all at once. It could be potentially dangerous to the business to even attempt to do everything and end up delivering nothing in the time we had. I needed to break that answer down, we needed focus and we needed to know what to do next.

When prioritizing features we’re making tradeoffs between them. We’re deciding that one feature is more important – and more valuable – than another feature. Anyone looking to compare two things to make a choice has to have enough information to be able to distinguish between the options. Without that ability, the tendency is to delay the decision by either doing nothing or asking for everything.

It’s the Burdian’s ass paradox, where an ass that is equally hungry and thirsty is placed precisely midway between a stack of hay and a pail of water. Since the paradox assumes the ass will always go to whichever is closer, it will die of both hunger and thirst since it cannot make any rational decision to choose one over the other.

Choosing feature delays whilst prioritizing forces the team to decide for the customer – who is inevitably not going to like the product they are paying for.

It has helped me to think of the prioritization process like selling a feature to the customer. According to Josh Kaufman in his book “The Personal MBA”, when the benefits of any product or feature are appealing there are nine Economic Values that are used to evaluate them:

• Efficacy: how well does it work?
• Speed: how quickly does it work?
• Reliability: can I depend on it?
• Ease of Use: how much effort does it require?
• Flexibility: how many things does it do?
• Status: what does it tell about me to others?
• Aesthetic Appeal: how aesthetically pleasing is it?
• Emotion: how does it make me feel?
• Cost: how much do I have to give up to get it?
.

I needed to get the business and customers to help define some of these Economic Values for our features so that we could compare and evaluate those features and make some decisions about their relative priority.

 

I started with the backlog.

The Agile backlog in Scrum is a prioritized list of all the work you have to do to complete a project. It can hold user stories describing features, but also contains bugs, technical tasks and spikes. It is a living document that reflects the current knowledge of what still has to be done. The product owner owns this list and regularly revisits the details in it, including the priority with the team and the customers.

At Allthings there was already a backlog. First time that’s happened to me. Usually, I have to make one. Great! What wasn’t great was that it turned out to be about 350 stories, bugs, ideas, projects in a flat, unprioritized, unestimated list. Basically a flat list of all the ideas anyone had had over the last 2 years. Where do you start?

I started by grouping all the features in the backlog into themes. In Agile, themes are bundles of features that are in some way related e.g. Onboarding, Internal Process, In App Communication, etc. The list was in allthings so I created a custom field for my themes, set the backlog list to ‘stack by’ that custom field and then drag and dropped features between the stacks in the stack view. Pretty handy.

Every time I wasn’t sure which theme to put a feature in I created a new theme. Some items would’ve been at home in two themes so I just picked the one that seemed the most relevant to me and moved on. I knew the backlog was a living document and would be viewed by many other people who would disagree and change individual feature themes no matter what I picked so I didn’t get too hung up on the first cut through the stories.

 

 

Now we had 10 themes to compare instead of 350 features. I sent an email listing the themes with a description to the whole company. In it I added as many Economic Values to the themes to help everyone compare them. Imagine this with some more detail on what a theme actually is and encourage everyone to get involved in helping organise the backlog:

• Views & Sorting – Flexibility, Ease of use, Aesthetic Appeal
• Sharing – Status, Ease of use
• Integration – Status, Flexibility, Ease of use
• Reporting – Flexibility, Aesthetic Appeal, Status
• Activity log – Reliability
 Import & export – Flexibility
• In App Communication – Status, Ease of use
• Mobile – Flexibility, Ease of use, Status
• Performance & scalability – Speed, Ease of use, Reliability
 Onboarding – Aesthetic appeal, Ease of use
 Account related – Reliability
 

Next I wanted to highlight actual customer-raised issues and stories. I went through our user support cases and User Voice feedback and tagged anything that had been suggested by a customer with a purple highlight. Customer-raised issues or suggested features are more important to us as how we deal with them affects our status with our customers and our reputation as a company.

So, the process of choosing which features to focus on were being narrowed down and prioritized. But this was only the first step. They next needed to be organised with values and evaluated, but more on this next week…