July 5, 2012

Tips for the Product Owner: Planning - Part 1 - Theory

Planning is the art of predicting the future as accurately as possible by assuming that past events - which brought to a positive outcome - would h...

Long Term Planning

A good plan allows better decisions

 Planning is the art of predicting the future as accurately as possible by assuming that past events - which brought to a positive outcome - would happen again in the future if we are able to recreate the same conditions. You could argue about the past being a good reference to make prediction about the future. I like to see it in a pragmatic way: as human beings, we base almost all our decisions about the future on what we have learned in the past. So far at least, the past has proven to provide supportive information to keep us alive.

Allow adaption by deferring decisions

A good plan allows for better decision making because you can defer them later in time when you really will need to make a choice and will probably have more information to evaluate the possible consequences of your decision. Additionally, a plan provides the guidance for a the team to focus on a long term goal and in this way a plan can also provide alignment. A team needs to be enabled to optimize the flow by removing unnecessary variations (Mura), while no resource or person in the chain gets overloaded (Muri) and eliminating wasteful activities (Muda). If you fail to allow enough room for adaptation to your teams, by deciding to early in the process, you will either end up constantly re-planning, or you will most likely encourage the team to stick to the plan.

Numbers are not the target, but indicators

For this behavior to emerge, it is critical to involve the team and clarify your expectations. If you present numbers as a goal, you will get compliance to those numbers as a result instead of what you expected as an achievement. You can use numbers as indicators for a real achievement. As a PO, you actually do not plan on your own, but facilitate the team’s planning. 

Don't pretend you can predict the future

The science teaches us that the nature of complex dynamic systems doesn’t allow to predict an exact end state. The best chance you have to guess what future achievements could look like, is to have a reliable measurement of the past. Scrum helps you by providing time-boxed iterations called Sprints, as soon as you have run enough Sprints you should have accumulated enough data to be able to determine what your team is able to achieve within a given set of time. Most Scrum teams tend to remain stable to avoid unnecessary variations and keep using those data effectively, so the achievements should become sustainable.

Common Pitfalls

There are some common pitfalls: remember that as a Product Owner you are asking the Team if they can commit to achieve a Goal for the Sprint that needs to be negotiable, and you are not instead expecting the team to complete everything they selected out of the Product Backlog.. By evaluating the team based on their percentage of completion of the items chosen out of the Product Backlog every Sprint, or their velocity, you will most likely encourage a compliance behavior to your expectations that might lead to poor quality, fear of failure and very likely to a very conservative attitude.

Estimate as an evidence for a good conversation

When you ask for an estimate, it is not about adding a number to a story. The real value of an estimate is that it is an evidence for a sufficiently deep conversation about the problem you presented and the suggested solution by the team. So if the team were able to give you an estimate, they understood what you need and also agreed on how to solve the problem. This is a very important step that reduces the risk of delivering something which is not what you expected or even block the team in the middle of the Sprint, because of disagreement. 

Learning is a valuable result

Whether or not the Team completes all the chosen Backlog Items for a Sprint, there is a very valuable learning for the whole Scrum Team and you will know better next time what to do different. The Sprint Retrospective, at the end of every Sprint, is a great opportunity to do root cause analysis about the issues encountered and consolidate the learning by adapting the existing process in the attempt of improving next time.

As PO, you can appreciate how the constant improvement of the Team is enabling  you to have more reliable forecast. First you might struggle forecasting a Sprint, but after a few, you will be able to make long-term predictions that are much more accurate than you would ever have thought.

Image of fivancsich

Franz Ivancsich

blog comments powered by Disqus
Image of fivancsich

Franz Ivancsich

Latest Posts

Jan Barnes joining agile42

Jan Barnes joining agile42 as an Agile coach in the Canada team

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.