“Yes, we Kanban” — Ferdinand Vogler

At ahead we spend a lot of time improving our process of building our product. We follow a Kanban-influenced approach. We ditched Scrum because there were a lot of time-consuming processes involved that didn’t serve us.

I’d like to share a snapshot of how we build our product. You may find this benefitial if the traditional To-Do, Doing and Done seems too limiting for you and you require more detailed stages.

Doing the right things

The following stages Idea and Research & Validate are handled with ProdPad. This is also where all our customer feedback comes together.

🎈 Idea

Where to product ideas come from?

Gathering feedback from customers (written, verbally)
Reading industry reports
Talking to co-workers that are in contact with customers
Looking at how customers use our product (in-person meetings, usability testings and data)
Coffee machine pitches, “Wouldn’t it be great if…”
Using the product yourself, therefore “scratching your own itch”.
Looking at competitors. Use with caution, every company operates in their unique context.

Gatekeeper questions

Two questions have to be answered to be allowed into the idea box.

What problem does this solve?
What value would it provide if it were solved?

The assumed value is also the hypothesis to test. Problems should be backed up by some kind of feedback patterns emerging. Problems are not solution proposals like “I need a bigger navigation button”.

📖 Research & validate

This stage is optional. Sometimes a problem is clearly understood and the “unknowns” about it are limited. In that case, an idea can go to Start development right away.

Each research method is tailored to the idea it should investigate. If the problem and value aren’t backed up by anything, but we think there might be something to this, we go into further research. Some undertakings remain an experiment and you never know how it will perform until it’s live.

Some ways to research and validate

Usability tests
Prototypes tested by customers
Talk to experts
Research data and eyeball potential impact to the product

Doing things right

If an idea has successfully gone through these two filtering stages, we create it as a user story in Azure DevOps.

🚀 Start development

The user story is ready for our development team to invest time into. They’re ordered from top to bottom from highest to lowest priority.

⏳ Refining

This stage is divided into two parts.

Doing

To be able to enter this stage, the team has to agree on the scope of the user story.
After agreeing on the scope, further refinement work can happen asynchronous. Designers verify prototypes, developers test a new technology.
Depending on the insights we gain above, the story gets further splitted into smaller parts than be shipped.

Done

In addition to a clear problem statement and value proposition, the following acceptance criteria about the user story have been answered and agreed upon by the team.

Feature

Functionality — what can it do?
Validations — is there some kind of user-inputted data that needs to be handled? What happens with confirmations, errors, warnings etc.
Translations — What areas to we have to translate? What’s the best wording to achieve the task?

Impact

Analytics — what do we want to find out with this? How can we prove our assumed value? How do we measure it?
Public website — any pages need an update? E.g. screenshots
Inform customers — how do we introduce this feature to customers. Any “heads-up” needed?

💡 Planned for development

Developers and Designers get together collectively to break a user story down into (technical) tasks. Clarify who will start working on what.

🛠 Developing

Getting our hands dirty! Firing up the code editors. Pair- or mob-programming works best.

🤓 Review

This stage is about getting an outside perspective and assuring quality.

Present to stakeholders. Stakeholders are people that should be updated about new product features. Currently this includes our CEO, sales team and customer success team.
Test if there are obvious usability issues or errors being thrown in our backend. If so, move back to Developing and iterate. Avoid “gold-plating” an idea. What is good enough?
Feedback in the form of additional feature requests or ideas are seen as new Ideas and go through the normal flow.

🎯 Done

Shipped to customers, well done.

How do you work?

How did you adapt Kanban to your team? What would you improve in our flow? This is always work(flow) in progress and I’d love to hear your feedback. Shoot me a message and let’s discuss.