Fabio Pereira

Prioritization is crucial for a project to succeed. We need to make sure that we deliver what’s most important, what adds more value. The interesting and most challenging part of this is when we have to ask the business (client, product owner) to prioritize items. By calling them items I mean they are not necessarily stories, features or a product backlog. Sometimes we want to prioritize needs, purpose, goals and outcomes as well. The way we ask them is the trick…

I’ve seen many different ways of defining the priorities and usually there are ranges involved, sometimes with labels or numbers, like:

• Very High / High / Medium / Low
• Must Have / Should Have / Could Have
• Essential / Important / Not very important
• 1 - 5

There is nothing wrong with creating the labels, but when we ask the priority of one item only, that’s what happens sometimes:

How do we understand business priorities

The most effective prioritization exercise I’ve seen was to give the business a randomized list of items we want to be prioritized, then we ask them to give us the X most important items. And these will be the ones considered during the next timeframe. We should always let the list visible to the stakeholder who is prioritizing… It has to be clear for him that he is giving up on items in favor or others… at least for the next timeframe, which could be the next iteration of release.

It’s like a son’s birthday gift…

Good parents apply this rule with their children. Let’s say it’s close to my son’s birthday, I don’t have a son, this is totally hypothetical :), but my mother used this rule with me… So, I want to buy him a gift, ONLY ONE, of course, because I’m not the kind of dad that gives everything that my son wants. So I have a list of gifts that I know my son wants. Bike and video game are top of the list, but I can give him only one now, because it’s his birthday. We all know It’s close to Christmas (next iteration/release) and I will give him the other one on Christmas, but now it’s his birthday time, only one gift… I, then, make sure that my son understands the one gift per event rule and ask him which one does he want as his birthday gift… As a clever boy, he will think carefully which one really matters more to him because it’s clear that he has to give up on one in favor of the other. He will not give up on it forever though, it’s just until Christmas (next iteration/release), however, he knows that one of them will be bought and received first, and the other will come later…

As I said, there is no problem in defining labels and priority buckets, the only thing we have to bear in mind is that whenever we ask the business to prioritize items, we do not ask them in which bucket he wants to put one single item. And that’s when the principle comes.

Principle of Relative Priority:

One item by itself is usually important, otherwise it would not even be in the wish list… If I ask my son:

• Dad: “Do you want a bike?”
• Son: YES!
• Dad: “Do you want a video game?”
• Son: YES!

But when they have to CHOOSE… That’s when the most important items are picked… And during times of crisis, like now, with budgets constraints, we don’t even know if we will be able to afford a Christmas gift, so let’s make our kids happy during their birthday…

Technical Agile, Cool, GFC, IterationMgmt, Prioritization, Scrum

My colleague Dan North facilitated a session today at ThoughtWorks office in Sydney about estimation, creating an MSL (Master Story List), what Scrum calls Product Backlog and which level of granularity should it be.

Dan started the session with a very interesting metaphor: If we want to calculate the area of a country we can always approximate it by comparing it with something that we know how to calculate… A triangle, for example. Dan used the map of the UK, I’m sorry Dan, I couldn’t help myself… I changed it to Brazil…

Basically, the area is something in between the areas of MIN and MAX triangles. And it’s very easy to calculate the areas of the triangles, right? How accurate is that? Of course it’s not 100% accurate, but most of the time we don’t need 100% accuracy. We just need to understand the boundaries in order for us to mitigate risks, which have been described as our “fears”.

The estimated range also helps us to make decisions. If a client wants to build an application, for example, and after calculating his current operational manual costs and what the application would make him save, he is willing to pay 1 million. But the estimated range is between 4 and 6 millions, this already helps the client to make the decision of not to proceed with the project.
Always bear in mind what estimates are:

“Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.” (wikipedia)

Another pertinent topic during the session was that the Iteration Manager (Scrum Master or XP Coach) should not only be focused on the lower level stories (Product Backlog), but also on the high level project goals and outcomes as well as relating them to the client’s and organization’s needs and purposes.
Stories can be grouped at a A higher level, which we call a theme. Prioritisation and estimation could also be done at these levels.

Some other things that I learned:

• The Pomodoro Tecnique - Timebox of 25 minutes
• Enough to proceed - do exactly what’s needed and enough to proceed to the next step, make a decision for example.
• The Slacker’s Guide of Project Tracking
• BE CREATIVE!

Technical IterationMgmt, Photo, Prioritization, Scrum, ThoughtWorks

If you won the lottery and you saw 10 million dollars in your bank account tomorrow, what would you do? You would probably buy a lot of things… right? But actually you do not need everything you would buy, do you? Ok, you would have a lot of spare money, so there’s no problem.

But what if you had only a hundred dollars in your account? What would you buy? You would have to think about it more carefully and prioritize.

The product owner needs to define what is really important for him.
If you ask him what does he want for a 2 years project (10 million) he will say: “I want everything!”, but if you break down the project into small iterations (sprints) and ask him to prioritize what does he want for a small chunk of time, that’s when the important things come up.

A good way to show the product owner that he does not have 10 million available is making him buy features with a limited amount of money.

How does it work?

Before starting the poker chips session, we need a list of estimated user stories. We call it Master Story List (MSL), or Product Backlog. There are many ways of facilitating an estimation session, I like planning poker. But always remember: The team gives the estimates.

Basically you need to define how much a story point costs and give a certain amount of poker chips to the client according to the size of your iteration. And then ask him to buy what he wants for the next iteration.
It is interesting because from my experience as long as he has money, he buys everything, but then when he starts running out of chips, that’s when the real process takes place.

The output will be a list containing the most important user stories at that time.

Technical Agile, IterationMgmt, Photo, Prioritization, Scrum, ThoughtWorks