3 steps to lean product development

Software is the core of our business. It’s how we enable our clients to accelerate towards a sustainable future. Here James, our Product Owner, explores how we stop scope creep and get the right functionality out of the door as early as possible. Is it skimmed though?

The scenario

The ambition is huge. It’s a new subject area, a new piece of artificial intelligence, a new product integration: it’s going to solve everything. You have the budget, the time and the team. The excitement is intoxicating and the creativity is flowing.

Now, the voice of realism. Yes, everything is possible, and that excitement must never be lost. But it will always be a balance of the development team availability, breadth, depth of scope and time available.

A motivated and engaged dev team is the most consistent variable. The breadth of scope is determined by our various stakeholders (future posts will cover requirement collection and prioritisation techniques). As a product professional, the easiest to manage is depth. Too much depth, or quality of a feature, is an inefficient use of resources and will prevent you meeting the scope or cause late delivery. Too little depth, particularly if unexpected from stakeholders, will cause kick-back.

So, I came up with this approach to communicate depth quickly and easily, and get everyone engaged with being lean…

A few terms before we get started (for more, see Mike Cohn’s writings)

  • User story = something the user wants eg I want to download my air quality data into csv
  • EPIC = a big user story, eg I want to manage air quality data
  • Feature = a collection of user stories that work together, eg I want to see an interactive table of my air quality data (some people, Mike Cohn included, call these Themes)

Skimmed, Semi-skimmed or Full-fat?

EPICs are translated and broken down into Features. Every Feature is triaged into 3 categories:

  1. Skimmed.

The first pass of a feature consisting of the bare essentials, the smallest and easiest user stories to get it out of the door as soon as possible. It will be usable and functional but will not be polished. This is to ensure we get it to our stakeholders as soon as possible, and react to what the user really wants, rather than what we think they want.

2. Semi-skimmed.

The second pass: developing a feature so that it becomes likeable. What this actually means varies, it could be most intuitive UX, better UI, the ability to complete tasks on mass. The focus here is ensuring a positive emotional response.

3. Full-fat.

This should be seen as a bucket of unstructured stories. All the extra ideas and curveball suggestions; items that will make that feature distinctive but ultimately are too complicated or niche to deal with now. This enables you to capture everyone’s requirements, and ensure stakeholders feel listened to. Ultimately, if any of these items come to the fore, spin them out into their own discrete feature and deliver the skimmed EPIC.

The response

Yes, the milk analogy is cheesy. It does get a few bemused looks and comments. However:

  • It clearly communicates depth across multiple features
  • Stakeholders understand what they will receive, resulting in more positive engagement and less negative kick-back
  • It drives efficiency, the focus is on the Skimmed EPIC, i.e. get the job done

The best response? Across the whole of the team, across designers, developers and our co-founders, I consistently get asked the question:

“Is it skimmed though?”

Share on facebook
Share on twitter
Share on linkedin
Share on email

Speak with our expert sales team to book a demo

Enabling responsible, resource efficient construction; cutting waste and carbon. Qflow automates on site data capture and auditing, feeding it into your existing tools

Get your free sustainability score today

Take our 2-minute quiz and we’ll send you a free report showing your sustainability readiness and what you can do to track, measure and reduce as-build project carbon