Garbage in, garbage out
This is a pretty basic principle. But what do you expect? What are the odds that if you give poor descriptions of your vision and needs that the results will be as expected? 50/50? Maybe less?
Within the agile community there’s a lot of information to be found on processes and the output of teams. What I’m really missing here is the discussion about the input. And bad input is very often the main cause of bad output. This input does not start with designs or architecture but starts from a business perspective. In this article I’ll focus on the flow of input from an early stage: from vision to user story.
Some causes of bad input
However in no way a complete list, some causes of bad quality of input are:
The product owner role
This role is often taken too lightly. It’s not about writing user stories and whether to attend a daily or not. It’s about product vision, entrepreneurship, stakeholder management, domain knowledge, user research, strategy, leadership, innovation and passion.
Big design up-front
In some cases there was a phase in which there has been made for instance a functional or graphical design before the development team was involved. But we want to do the project agile because we want to be able to prioritize and build the software iterative. So we split the designs up and create a backlog based on the items in the designs. How is this different than implementing a big design upfront in basis? Do we now really know that we are creating the maximum business value?
“If the big design upfront was wrong, why should the quality be better if we cut it up?”
No focus on business value aka Quantity over quality
We really want it all. So we just define as much stories as possible. We do not really have to implement them all but we still define as much as possible. The bigger the product backlog the bigger the chances are that we will get a lot of functionality.
Why, What & How
We sometimes answer these questions in the wrong sequence. Sometimes customers start with the how and we go along with that (A man went to the Doctor) and sometimes we skip the what. To really define and secure the business value we really have to follow this sequence: Why, What and only then How.
The flow of input
What to do then? After seeing a gap between business and IT over and over again I started looking for ways to help the business to get a better connection with the way we do our agile projects. To help product owners to communicate better between stakeholders and development teams. I found some really helpful ways of thinking and tools which I like to use in order to create a good quality of input. I didn’t invent these tools or methods. This is the work of people which I admire for that. I’ll only describe a small part of each subject. I provided some links to their sites so you can get in depth information written by the experts.
The agile product vision board
We need a clear and common understanding about the goal(s) of the product we are going to make. We start by defining the product vision. We specify a vision statement, the target group(s), the reason why we should make or do anything (the needs), your crucial features (those can become your epics) and what value it is going to bring the stakeholders.
We now have a common understanding about the goal on which we can verify all the choices we have to make in the future. Whether you are a developer, product owner, stakeholder, user or tester. We know the target groups on which we can define our personas, we know which problems we have to solve/which business value we have to create for these personas and we have our top features. These top features we now can easily use for the next step: the story map
The story map
The reason why I like to use story maps instead of flat backlogs is because flat backlogs are very difficult to understand. Most of the time they need explanation for the people who are not directly working on it (stakeholders for instance). It is just a flat illogical list of splitted functionality.
A story map is a two dimensional backlog which makes your backlog and release planning both much better readable, logical and understandable. Not only for the development team but for everyone who can read basically. It will show you your planned releases and what they contain in one glance.
The principal is very simple (as very common with good ideas). At the top of the map from left to right are the “big stories”. Let’s call these activities. It is something an user wants to do with the product. The order of these activities explaines the behavior of the system. Underneath these activities we put our user stories, prioritized according to their value.
As Jeff Patton puts it here: ”I simply arrange the small things under the big things in a bit of a grid form.”.
If your story map is ready just take the top row(s) of features, the most important ones, and work them out in a product canvas. This set of features can be your minimal viable product. It contains only the features which you need to have your (first) version deployed. Now you can finally get some real feedback from the users you’ve defined in the product vision. Inspect and adapt.
The product canvas
This is something that helps teams to get the stories for the next sprint ready just in time. This gives a clear and focussed view on what there needs to been done on the short term to get ready for poker instead of a big design upfront. I found out that it is also very helpful for getting (UX/graphical) designers and architects, who are used to create designs upfront, faster in a agile mindset.
We take our most important features from the story map, add the personas, describe the journeys these personas can take, describe the constraints, do some basis or overall design and combine all this data to write stories which are ready for poker. This is the input for your sprint. And after the sprint planning you start over again with the next set of features.
Finishing up
As stated above, I like to use these tools to bridge some of the gap between business and development teams. To create a common understanding about what we do and why we do it. To do really successful (agile) projects we need everyone who is in any way involved to have that understanding. To maintain this we need to have this visible, understandable and accessible for everyone. I found that the examples I described above are great for that.
By taking flow of input serious, like we should take the PO role much and much more serious, we can create qualitative input. The odds that the output will be qualitative will then be also much higher.
For me there is one downside. I consider this a luxury problem: you really need a lot of room on the walls.
In-depth explanations:
- The product vision & the product canvas (also the business model canvas ) as explained by Roman Pinchler
- Story mapping explained by Jeff Patton.
- The business canvas generator by Alexander Osterwalder and Yves Pigneur
Was this post helpful?
More articles
fromNiels Talens
18.9.2016 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Niels Talens
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.