Planning the product backlog

Focus on the Goal as it defines your future

Before we dive into product backlog planning we must understand a little more about LTP which stands for Logical Thinking Process.

Eliyahu M. Goldratt author of the best seller “The Goal” a management novel, he is also the Inventor of Theory Of Constraint and the Logical Thinking Process, both are described in the book The Goal.

In the book The Phoenix project which is modelled after The Goal but focusing on DevOps you will get the good perspective of the challenges in development and operations and how to deal with the constraints and understand the Critical Chain concept.

The Phoenix project is a fantastic and amusing book and you will recognise the people in the book and you know most of them in real life.

In the book The DevOps Handbook by Gene Kim, Jez Humble, Patrik Debois & John Willis that is describing how we can realize The Phonix project in reality they have following statement about DevOps (Part 1 page 4);

DevOps is the outcome of applying the most trustful principles from the domains of physical manufacturing and leadership to the IT Value stream.

DevOps relies on bodies of knowledge from Lean, Theory of Constrains, the Toyota Production System, resilience engineering, learning organisations, safety culture, human factors, and many others. Other valuable context that DevOps draw from include high-trust management cultures, servant leadership, and organizational change management. The result is world-class quality, reliability, stability and security at ever low cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and Ifosec.

The foundation of DevOps can be seen as being derived from Lean, the Theory of Constraints, and the Toyota Kata movement, many also view DevOps as the logical continuation of the Agile software journey that began 2001.

Why do I bring up DevOps, Theory of Constraints? It is because you likely work within IT and in IT DevOps, Theory of Constrains are two of the most important knowledges to be success full with your Value Stream.

Making DevOps work, will make it possible for you to have fast TTM with quality and cost efficiency.

The Theory of Constrains will help you identify your bottlenecks and get rid of unneeded waste.

The Logical Thinking Process is also described by a man named Bill Dettmer as A Systems Approach to Complex Problem Solving

Logical Thinking process is about change, but changing the right things by knowing what you have to change and to what to change it to, to be able meet your goal.

The Logical Thinking processes is also a toolbox and you find following tools inside;

Goal Tree

Current Reality Tree

Future Reality Tree

Prerequisite Tree

Evaporation Cloud (Solve conflict win – win solution)

As product owner you must know where you are heading, and the LTP helps you do that!

From a 10000 m perspective of planning it is a bout defining the objective or Goal

Surrounding the Goal we have a circle of Needs the, things that must happen to meet the goal.

The outer circle is named Actions, here we have things we want and believe has to be done to fulfil a need.

There is often many actions required to fulfil a need.

This picture can be used in many situation and I will use it here in LTP4Scrum in a few situations.

If the Objective is the Goal for your Value Stream, then the Need circle contains your Critical Success Factors that must happen to make your Goal happen!

And the Action circle is your strategical and tactical actions that you have decided on to meet the Needs and bring you to the Goal.

The Planning circle is readable if you start in the middle with the objective and read it outward it is read like this;

In order to “Objective” we must “Need(1)” and we must “need(2)” and we must (all needs)

In order to “Need (1) we must ”want(1)”

In order to “Need (2)) we must “want(2)”

When you plan you can move this circle with you, so when you start breaking down your want, you can put that as your objective and define the needs for this and the actions you want to take, but that is another story.

Do you believe in conflicts?

If you do not, start believe now! You will have the conflicts anyway so get prepared to make solutions that are of the type win win.

If we look at the planning circle, we have an objective, we have needs to be fulfilled and we have actions that we want to do to fulfil a need.

Most conflicts is in the action sections, we have needs and we have actions to fulfil the need, and this actions are in conflict with each other.

What is a win win solution?

It is when the need can be satisfied without any compromising’s, as that make the purpose of our wants to be fulfilled as they intended to fulfil a need.

Find alternatives to the wants and make sure that they meet and fulfil the need. Doing this will result in a win-win scenario due to that we are not compromising our needs only how we fulfil them.

I will not dive into conflict resolution more deeply as that requires its own article.

The Goal

If you are like Alice in wonderland the Goal might not matter, but if you actually want to go somewhere it does!

Yes the Goal is the most important thing you have to define, it defines the purpose it defines the future it defines where we are heading.

To be able to define the goal you also have to understand the context of what you control and what you can define as the Goal.

You must understand the system.

System? What do I mean by system?

If the Goal is defining my companies Goal, then the company is the system.

If I define a project Goal, what is the system, you have to identify the system for which your project are delivering or is trying to create.

For a product owner as you and me, the system is our product our value stream.

Let’s look at next picture to get a better understanding of the context of a system.

Do you see me, yes the pore man in the left top apartment that’s me.

What goals can I define?

I need to understand my system and how it is built up.

The system is based on 3 parts, the things I control, the things I can influence and the things I have to accept.

I am in control of my living and my apartment.

I can influence my noisy neighbours

I have to accept the weather, I have to accept laws, I have to accept the things I can not control or influence.

Do not make the things you have to accept into road blockers, make them part of your game and play well.

When you define your Goal, do it on the things you can control, you can put in the things you can influence as tactical and strategical decisions but not as your success factors and not as your goal.

Burn your energy on the things you can control and not on the other things, yes do influence and utilize your influence, to boost your goal, but do not rely on it.

Lest look at our planning circle again.

We now has a clear understanding of the system, what we control, what we can influence and what we has to accept.

The game board is defined so to say.

So lets start making our plan, how shall we play this game?

What do we want to achieve? What is our Goal?

In my case I am the product owner for Business Management Services, our VP has decided that the Goal is that our services shall be the most user friendly in our customer segment.

Our Goal will fill the inner circle (Objective).

I am the product owner, and my Objective is to “Provide Business Management services that are consumed by our customers”.

How do we make this possible? We must define the needs.

A Need is a break down of the Objective into a more detailed level our Critical Success Factors.

We must put in our needs around our Objective, the needs is the things we must have to fulfil to make the objective possible our Critical Success Factors.

Lets brainstorm a little, what needs do we have?

  • User friendly services
  • Easily accessible services
  • Meet the customers functional demands
  • Quickly comply to customer needs
  • Minimize inventory
  • Minimize operational cost
  • Maximize throughput
  • Earn money on the product
  • Price competitive

But what is the last things that has to happen to make the goal possible, lets try to pick the 3 best ideas from the brainstorming.

I will also rephrase them to be a full sentence

  • User friendly services
  • Easy accessible services
  • Quickly comply to customer needs

We need a strategy for how we want to fulfil the needs.

  • Provide User friendly services
  1. Have Responsive and dynamic applications
  2. Provide Intuitive features that make manuals obsolete
  • Have Easy accessible services
  1. Have a Web GUI
  2. Have Iphone and Android apps
  • Quickly comply to customer needs
  1. Have a Modular system to be easy to extend and change
  2. Provide core business management services

The Need Circle shall contain 3-5 needs

The Action circle shall not contain of more that 5 wants per need

The action Circle should not have more than 2-3 layers and not more than 5 wants per parent want.

Defining the road

The Planning circle have helped us define the road with a clear Goal, the Critical Success Factors and our strategical and tactical decisions to get there.

The strategical level is a bit simplified, we must break it down to more details in some areas, but lets for now stick to the principals.

This process will take you some time and you have to think it trough to secure that your needs are expressed (the Critical success Factors) so you know that you have captured what is needed to meet the Goal.

Your strategical and tactical decisions are equally important, but will likely change over time, whiles your critical success factors will be more stabel over time.

One way of validating the tree is by reading it, and by doing this we will adjust the sentences in the boxes to be clear and precise.

The sentences shall not contain any ”and” and “or”, if they do, you have to break them apart into two boxes with a clear sentence in each.

Lets validate the tree by reading it, and if we stumble on the words or have to add in or change the sentences, we need to corect this.

We read it like this; In order to <item> I/we must <item>

In order to Provide Business Management services, that are consumed by our customers

We must Provide User friendly services

And We must Have Easy accessible services

And We must Quickly comply to customer needs

Now we continue with each branch and read them one by one;

In order to Provide User friendly services

We must Have Responsive and dynamic applications

And We must Provide Intuitive features that make manuals obsolete

In order to Have Easy accessible services

We must  Have a Web GUI

And We must Have Iphone and Android apps

In order to Quickly comply to customer needs

We must Have a Modular system to be easy to extend and change

And We must Provide core business management services

It sounded readable, yes it is important that you read it load, by doing so you will hear when a sentence is not good and it will also imediately trigger your analysing capability and your stomach feeling for it this is sound or not.

Implementation circle, stories and epics

We have a product Goal, we have our Critical Success Factors, we have lined up our strategical and tactical decisions.

We have a product definition and value stream definition we now have to plan the implementation.

In scrum we do this by defining epics and stories, start with your high level epics and break them down to more concrete stories and use your team/s to help you break the stories down into consumable stories.

Lets have a look at an example of how you do and how it looks like in next picture

Break down your product/project definition into stories

The principals for creating the stories is the same as we did when we was breaking down the goal and the critical success factors.

We ask our self what are the last things that have to happen for this “item” to happen.

In above picture we have a plan with a story tree, that was created by asking our self “what is the last things that has to happen to see the movie”.

We validate the plan by reading it out load.

In order to see the movie I must buy a ticket to the movie and I must Drive to the cinema

In order to Buy a ticket to the movie I must select a movie and I must have money to the movie ticket

If I am 10 years old, this is not a valid plan, what is more needed to happen for me to see the movie

I must have my parents permission, and the film must be allowed for my age.

And we must tweak the stories, stories so someone is driving me to the movie.

Yes this is a very simplified example and probably not real stories more actions in a story, but I liked it as a good exampel.

Planning and execution

When we do our product planning we do the planning from top to bottom by asking our self what are the last things that has to happen for this “item” to be possible to happen or fulfilled.

The execution is done from bottom to top always start with your leafs of the planning tree.

Your product/project plan is easy to read and understand with the simple reading logic In order to “item” I/we must “item”

If you put this on a visual place you can also use the traffic light coloring showing the current status and where you have issues

Red indicates we have a stopper

Yellow indicates that we have not a full delivery

Green is off course showing that we are done

I have in my plan added a sub tactical decision, saying that for our web GUI we will use a backend based on php and mysql.

I have started my plan and defined two stories Setup Backend Server including backup and Select hosting provide for linux server.

As this is a guide I have just showed this small section of my product plan.

Now it is time to do the implementation and gather my scrum team to review the stories, fine tune them and let them start there sprint planning.

Sprint Planning

We have also broken down one Strategic decision into Story’s so we can run a sprint.

Our first sprint, we check our performance records to see how many story points we have and we have to adjust based on that our team now has one member short due to the flue.

We are able to fit in the two story’s in the above picture, and starts discussing the Sprint goal, we decides on that the sentence in the Strategical/Tactical box is a good definition (Backend written in PHP and database MySql) but that we should polish it a bit to be more of a gaol statement.

Sprint Goal is to have a backend system based on php and mysql.

Create sprint plan

Break down the stories into tasks

Clearly identify any dependencies especially to other teams, but also to your resources available for this sprint

Define your sprint goal, the sprint goal will help you focus and prioritize activities during the sprint

Do not forget to use the product owner throughout your sprint to help you succeed and with clarifications.

We have our stories and we have to validate that we can do them, by making a sprint plan.

During our sprint planning we need to identify all dependency’s, especially to other teams.

Dependency’s to other teams are going to limit your ability to deliver, so consider if it should be your problem or the product owners.

If you think you can handle it, go along, if you are uncertain, setup a meeting with product owner and break down the stories into what you are responsible for delivering in your sprint, and postpone stories that has dependencies to other team until product owner has solved the depended new sub stories.

There is off course tons of variations for this, so make your best decision, but do not take responsibility for things you can not deliver.

Plan your story’s by breaking them down into tasks.

Take the first story and ask yourself, what is the last things that has to happen to make this story happen?

In order to “story” we must “task” and we must “task”.

Then take each of the tasks you have identified and do the same thing, what is the last things I have to do to make it possible to execute this tasks.

In order to “task” we must “task” and we must “task”.

This is a bit tricky to do for the first time as most people are not used to do it this way, most people start from the bottom and goes upwards, but do not do that you will fall in to traps and might end up with something else than what you need.

Do the same thing for the other stories and when you see a dependency make the needed adjustment to link the tasks together with the stories.

We need to validate our plan, the best way is to read it as stated above, in order to <task> I must <task>.

If you can not read your plan out load something is wrong, ether something is missing or the wording is not correct.

Make sure each action is a clear sentence, this will help you in a number of ways, the task will be understandable, and can more easily be debated and it makes it easy to read the plan.

We have now a readable plan, do not rush on, we are not finished with validation yet!!!!!

For each task ask yourself is there anything else that also has to happen to make it possible to execute my task or to meet the story?

It usually are, often when I do this and go over the plan again I usually find one or two missing actions, so take this time and do a good job.

The planning normally takes less than an hour.

It’s time for next phase, the time simulation so lets tilt our plan 90 degrees to the right!

Sprint plan time simulation

We now have a perfect timeline, where we have the leafs at the left and the sprint goal at the right.

The tasks dependency shows the execution order, and some time like this we can see that there is tasks that can run in parallel.

When I was young and was in school we read a book written by a famous Swede named Fritiof Nilsson Piraten, on his gravestone following text can be read;

“Here lie the ashes of a man who habitually put off everything until tomorrow. However, he improved to the utmost, and actually died January 31 1972”

Do not follow his footsteps and postponing things execute all parallel tasks as soon as possible, as you have a slack like in our plan the two top left tasks has a slack, make sure that those are not going to delay you, there is slack time but do not waste it and wait until last minute, if you do they will actually end up as your blockers.

Why have we done this simulation?

1.We have identified things that can be executed in parallel and how much time we have to do them before they end up as our constraints

2.We can now inform the product owner when we will deliver our stories to them, which make it possible for them to coordinate other tasks and delivery’s from other scrum teams or it might be we that other teams are waiting for and needs estimation of when we can deliver, do not for get that

3.The simulation makes it clear what you as a scrum team has to do and when it has to be finished for you to meet your deadline which is the end of the sprint, but do not forget that you have a commitment of delivery, so make sure you make it

4.The last but still important, you will forget things, so things will be added and the plan helps you see the consequences for missed things

5.Ok last thing then, I promise make sure you have some slack in your sprint, you will need it.

Good luck now with your sprint plan and execution

We are now done with our sprint planning and execution, lets take a step back and look at what has to happen before our sprint planning which is product backlog planning.

Hope this was of interest and that you try it out!

Leave a Reply

Your email address will not be published. Required fields are marked *