When developing software, teams discuss what can be done and what cannot be done given available resources, skills and technology. Three dimensional scopes visualize the potential for this kind of negotiation: they question breadth, depth and the newness of features. This comes in especially handy, when the scope appears to be tightly defined.
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 readingClassifying 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.
The stuff I find most exciting is making something work for the users or to put it in more modern terms: people have a great experience when using something I helped create. So I focus on users and user experience. Some people rather talk about customers and customer experience. Whatever the name, it is basically the same isn’t it?
Here’s the situation: A customer asked us to improve the quality of their core system so that they again can act on the demands of their users and customers in a timely manner. We had a team room at our disposal and we again made extensive use of the walls. It turned out that the team wall made the difference!
Keeping knowledge about a product alive is no easy task. Software teams struggle with manually mainting vast documentation in UML tools, text documents, wiki sites and more. We all know about the amount of effort and dedication needed to do this well given the amount of redundancy. There is a promising vision of a living documentation, i.e. a documentaiton automagically created from those things the teams create anyway, like automated and manual tests, backlog items, meeting protocols and more.
The stars to road innovation framework wouldn’t be complete without the concept of stories. The story decides the fate of the innovation. It can prove to be very powerful.
Even though – as a UX professional – I must stress the importance of meeting users, I have to admit that the title of this article is not exactly accurate and just meeting users is not really the point. Having revealed this, I should probably explain what really matters when meeting users and give some indication on how to do it. This article covers two stars to road essentials: the UCD cycle and the UX levels.
Lets start at the beginning and lets review a first big challenge creators of great products are facing:
Continue readingIn 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.
Agile practice recommends to focus on business value. Those items with the highest business value should be implemented first. At the goto zürich conference held in April 2013, one recurring topic was how to prioritize backlog items.
Continue readingIn order to create great products, know how is needed. Interdisciplinary or cross-functional teams are the way to make people with different expertise create a common solution. Here’s a puzzle piece for cross-functional teams: 6 generic areas of expertise needed in a product development.
Pin the maturity cards on the wall. Ask how well do we foresee the change we’re going to inflict with the planned features. “Customers will love it”, the engineer proclaims putting a few features on tree level. The sales rep sourly adds: “If they’ll ever grasp it”, moving them up into the clouds.
In large and distributed companies the knowledge is spread. Experts come from different locations and subsidiaries. These experts often work in several projects simultaneously. This leads to an efficiency loss and long product development cycles. What if there is a way to get rid of dozens bilateral and specialized division workshops and preparation meetings? The approach is called approach “Speed Creation”.
Continue readingAsk this question in a workshop to a round of engineers and product managers. After a few blank stares you will start hearing comments like “we’re ready to build it”, or “they’re pretty sound”, and “well, we actually have no idea what this is all about”. Quite often we hear completely different opinions about the same item. Try it yourself, it works. Stunning, isn’t it?
Continue reading