Why – How – What: From Product Vision to Task

Nice Post Peter.
Although something confused to me. The why is very clear, but I tend to mix up between the what and the how.

You assign the how to the product backlog, but that is more easily represented in my mind as a description of thing (a noun, not an action)
On the other hand you describe the what as the tasks (or actions) to do during the sprint, in this case verbs (not names) would came to me more easily.

Thank you

This is great info. I tend to differ in a minor way, with my understanding. The vision is the why, the Product backlog is the what we need to do to achieve this vision and the scrum team comes up with how to achieve this. so while i fully resonate with your narration, switching the places of what and how relates better

This article means a lot to me, "people don’t buy what you do, but why you do it" this literally opened my mind, We developers constantly develop solutions without know why we do what we do, frequently focusing on how but now I have a clear vision to get my work well done, as a metaphor, my hobby is drawing and some day I read an interview to a famous mangaka (manga artist) from Japan and he was asked about his trick to draw some clear and straight lines, his answer was that instead on focus on how draw the line straight, he focused in the final point of the line to draw the line.

Wow, thank you for sharing the view "people don’t buy what you do, but why you do it". I think people care more about “why”, because they always, or even only care what problems (pain points) you exactly help them resolve.

Thank you very much for your feedback. Today I re-visited this blog post from two years ago as I wanted to check if my view has changed, especially in regards to the changes to the Scrum Guide and the newly added Product Goal.
And my view has changed. These days I would say that the Product Backlog is the WHAT, and the tasks are the HOW.
So I fully agree with you and will update this blog post in the near future. Thanks for pointing out your doubts.

Dear Gayathri,

thank you very much for your feedback. After re-visiting this blog post I fully agree and will update it soon.

Dear David,

thank you very much for your feedback. While learning to ride a motorbike I have also learned to have the target in mind when entering a curve. If you focus on the area directly in front of your front wheel you will not arrive where you would like to. To drive the optimal line you have to focus on the point where you want to exit a curve.

Thanks for the drawing analogy, that illustrates it nicely (pun intended).

Dear Daisy,

thank you very much for your comment. I agree that to know about the problems we are trying to solve will help us solve the problem. This problem is the WHY of our work.

Me encantó esta información! Muchas gracias...:)

Hi Peter. Great Post!

I have been using Simon's 'Start with Why' theory in my scrum teams for the last few years as well, so your post really resonates with me. I love the simplicity of 'Why' and the simplicity of Scrum, so they go hand in hand in my mind.

I haven't seen the golden circle used to equate to scum artifacts before - that is quite fascinating!

If you go get a chance to review, perhaps you would be interested in this point of view that your idea made me think of (and this is maybe taken a little more from the updated elements of the 2020 scrum guide)...

The Why could relate to the 'Product Goal', which is what I actually thought it reminded me of the first time I read the updated guide (or even the sprint goal).
The How could be the 'Definition of Done' as this guides the scrum team along the way to know how we deliver an increment.
The What could be the 'Increment' itself as that is the end result of the sprint\release and represents that value we are actually delivering.

Hope you also found this interesting. Thanks for listening. :)

Hi Matthew,

thanks for sharing your perspective. I agree that the Product Goal is a much more actionable and concrete 'Why' that can help Scrum Teams to find the right direction and stay focused.

I have used the Golden Circle in regards to the work the Product Owner does and therefore matched it to the levels of planning reflected in the Product and Sprint Backlog. Your idea to include the Increment and its commitment is interesting and I need to think about it. I can see that the Definition can guide us to think about how to deliver usable and useful Increments, but that doesn't mean any real value has been created. Therefore I hesitate to fully embrace your ideas.

To me it seems like we come from different directions. I come from the work the Product Owner does, I think you see a broader perspective from the customers' and users' points of view. I like this as it is the most relevant thing we try to achieve in the end.

Thanks for giving my brain something to chew on and think about. It will need a few days to make up my mind about it and form an opinion.

Did you publish your thoughts anywhere in a blog post or similar in more detail? I would love to read more about the background and thinking of yours (and properly quote you if I use it in my classes and coachings).

I see the value in this way of thinking, not quite sure if the developers will. I myself as a developer would deem this as a waste of time/energy that could be spent thinking how to implement things in the best technical way, if I hadn't read the scrum master pathway to this point.

Hi Martin, thanks for sharing your view on this. I agree that often developers focus a lot on how to do the things right (I am doing that at the moment, evaluating and selecting technology for a green-field application). And I think they should have a focus on that. As long as they join the Product Owner in understanding (and maybe even shaping) the "Why" of the product this can help them find the best "How".

It is the heart of problem that every team stuck to it especially the developer when the don't have any business knowledge about the product they develope

That is a very good point, Majd. I think it is crucial to have understanding about the business and the value a product should/will bring.

Seems like Sinek's circle is not in logical order though. Understanding Why there should be a change and then What that change would be, you then reverse engineer to How that change can take place. Why - What - How seems to line up much better with Vision - Product Backlog - Task

Thank you for the good Article.

I think within the why you should think about the "hard problem" that your product will solve different / for the first time. The book "crux" by the author Richard Rumelt descripes this in painful clearity.

Since that understanding that why needs a "problem to be solved" the whole topic got way more useful for me.

Thanks for sharing your thoughts, Thomas. And also thank you very much for the book recommendation. I don't know this book yet and have put it on my "to read" list.

I was about to add the exact same correction. :-)

Hi Mike, hi Marc,

thanks for coming back to this older article of mine. Since 2018 my view on this topic has changed, and so has the Scrum Guide. And I agree that the three topics of Sprint Planning align perfectly with a slightly adapted version of Sinek's Golden Circle. Therefore today I would definitely start with the Why (Product Vision), continue to think about What to do in order to
get nearer to it (Product Backlog) and then think about How to build and deliver it (the plan made by the Developers).