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.
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.
- 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
Stop starting with Scrum
Don’t worry: I am not going to jump on the “agile is dead and a failure” bandwagon. I do not want you to stop working with Scrum. I just want you to stop starting with it. A lot of companies realize something’s got to change in order to survive. Especially...
18.9.2016 | 2 Minuten Lesezeit
Impact mapping and continuous validation
There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact? Whether we want to make an app that that seamlessly connects riders...
- Open Source
- Agile methods
25.11.2015 | 3 Minuten Lesezeit
Continuous Validation: Meet Gareth. He is seriously unpleasant.
Hello world, please meet Gareth. He can be seriously unpleasant. Trust me, we know. But he is becoming more and more indispensable. He will tell you clearly, without emotions, when your ideas are rubbish. He will certainly not hold back and he will give...
15.9.2015 | 3 Minuten Lesezeit
After continuous integration there is continuous validation
It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software...
- Software development
23.8.2015 | 3 Minuten Lesezeit
How assumptions are not the mother of all f-ups
The thing about trends is that they will come and they will go. So after the agile trend continuous delivery and devops are in line. I think in a way it is very nice to see that development craftsmanship practices are becoming more and more accepted....
13.7.2015 | 5 Minuten Lesezeit
DevOps, building on quicksand?
The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering...
24.7.2014 | 4 Minuten Lesezeit
DevOps and Product Ownership
[This article was co-written by Miel Donkers and Niels Talens.] You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help...
17.7.2014 | 7 Minuten Lesezeit
A man went to the doctor…
“Hello Doctor, I have epicondylitis lateralis and I think we can fix that with Shockwave. Shockwave is a brand new treatment that is faster, cheaper and better than all the other methods. Everyone I know does it. Don’t bother looking that up for I’...
9.11.2012 | 2 Minuten Lesezeit
Velocity is not for you
A while ago someone told me they let their product owners participate in estimations. And I don’t mean watch how the team estimates but really estimating stories. I’ve heard about non-programming scrum master, projectmanagers, salespeople and architects...
- Agile methods
- Software development
7.10.2012 | 2 Minuten Lesezeit
RST Testing Training – James vs. Michael
I was thinking to get James Bach to the Netherlands because he has an interesting view on testing. I read a couple of the books he wrote, watched a presentation from him on video . I thought he has a lot to tell. Beginning of this year a new colleague...
22.6.2012 | 4 Minuten Lesezeit
Lean specifications, what’s that?
A lot of teams are changing to Agile. Usually they start bottom up with a development focus on getting agile. The testing is often late in the change process and testers are not that keen on this new process. This is quite logical testers don’t change...
6.9.2011 | 2 Minuten Lesezeit
Lean bells ringing at the hospital
Last week I was working at my house together with my father and we removed a wall to create a bigger room for the upcoming baby. While the last stone was removed he damaged his thumb quite badly. We needed to go to the hospital. As soon as we arrived...
18.6.2011 | 4 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
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.
Do you still have questions? Just send me a message.