It is sometimes beneficial to ramp up a large software step by step. This promises doing earlier business, reducing risk and gaining momentum. Just slicing a large development into arbitrary pieces will however not work well. Teams need a bit more strategy so that each delivery is useful and provides significant value. This article introduces business scenarios and 6 slicing patterns that help product owners and agile teams to align incremental product development with growing the business.Continue reading
Category Archives: 06 – Delivering business value
From exciters to liabilities
Classifying customer expectations, Noriaki Kano created the well-known Kano model more than 40 years ago. I felt this model deserves a more in-depth presentation on stars to road for a couple of reasons: First, it helps to prioritize features over the lifetime of a product. Second, it points to typical issues you encounter during product development and provides hints how to improve. Third, it is not too difficult to assess the categories and they are easy to understand. Fourth and most important: you need good understanding of customers and markets to work with the model, a real indirect benefit! All in all, the Kano model is an important foundation in product development one should know.Continue reading
Requirements – an agile answer
Understanding what people need and require from a product is important. So requirements are important. But what is a requirements and what are “good” or “bad” ones? I set forth to find the ultimate answer and found 42. So lets add a bit more structure and talk about the problem, solution and the conversation side and conclude with a question: where should the development team invest their energy: into creating the specification or into discussing the best possible solution given the constraints?
The case of a relevant UX problem
This is not about a Sherlock Holmes mystery and no engineer lost a thumb over it. Even though the machinery involved could easily achieve the latter. It is about industrial robots and tons of machinery to fold metal sheets into origami swans. But mainly it is about a case where creating the right user experience solved the relevant problem.Continue reading
Agile conversation or requirements engineering?!
Requirements engineering (RE) has a long and successful tradition. Different approaches always existed. Still it is optimized for an artifact driven setup: Individuals pass on documents. Agile practices are however geared for an interaction driven setup where individuals form one “super-brain”. The discussion about requirements is part of the agile conversation. And now, the proven approaches from RE suddenly create friction and bad smells. So, should we forget about requirements?Continue reading
User story shopping – a sports event management system
The challenge awaits our project: How to deal with the many expectations from our customers that are far beyond the project budget? The answer in my current project – the sports event management system – is based on user story mapping.Continue reading
grok – negotiate – build up
In our current project, a software for managing sports events, user stories play an important role when it comes to development. Interestingly the focus of the requirements conversation changed completely from one level of maturity to the next. And there is a pattern behind it, as it seems. It leads to user story mapping.Continue reading
A case for features – a sports event management system
Currently, I’m involved in a project to develop an event management system for large sports events. The goal is to replace a few existing systems with one integrated system that is able to cater for the coming needs. End of elaboration is closing in and we’re planning for the incremental delivery to follow during construction. Budgeting, estimation and release planning all turn around features (Part 2).Continue reading
User centred business analysis – a sports event management system
Currently, I’m involved in a project to develop an event management system for large sports events. The goal is to replace a few existing systems with one integrated system that is able to cater for the coming needs. The project will last for about five years. The project team will grow to approximately 20 persons. We apply an agile unified process.
Part 1: Understanding business is a success factor. We use methods from user centred design rather than from business modeling.Continue reading