Blog

    Contact

Business priority, planning and estimation in Agile

Dec 1, 2019

Most of us have all seen MoSCoW used when assigning a priority to a business requirement. In case you haven't, MoSCoW is an acronym for:

  • Must – Without it, there is no system. What is a must in your software?
  • Should – Without it in the system, it will be a struggle and a work around may exist..
  • Could – It is good to have the feature, but it would be easily missed from the software.
  • Won’t – A decision is taken that the feature is not needed.

It sounds great in principle - very simple, but it's not very granular and if there are a lot of requirements it doesn't allow for real prioritisation. 

The backlog is effectively an ordinal list of priority that allows the features with the most value to be developed. But how can we refine this list beyond the very blunt four statuses given to us by MoSCoW? How can a Product Owner stress to a development team what to work on when there are 100 Musts but capacity to only build 20?

I've seen this many times; a business owner is confronted with a long list of equally rated requirements and becomes paralysed. What is often not considered is the business value and cost of each requirement. If paralysis is reached a useful technique is to find and apply a relevant metric that can quantify the value and cost.

This can then be converted into a prioritisation matrix to give a visualisation of the relative importance of each item.

Can we use another method?

Prioritising with Fibonacci sequencing

Some teams will prioritise by abstract measures such as t-shirt size (XS, S, M, L, XL, XXL). If it works then great.

My preference is to rate business priority using a Fibonacci scale. This is more discerning than a sledge hammer MoSCoW approach. A Fibonacci scale consists of series of numbers where each number is the sum of the previous two (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc).

As the numbers increase, they become further and further apart. That means its easier to give a score with scores of 8 vs 13 than deciding between scores of 8 vs 9. This is why I prefer it over regular increments, for example from 1-10.

There will always be items that people understand well and can clearly and definitively say are the most important. There will also be another slice of items which are well known and can be said to be very important, but not quite as important as the previous ones. Eventually we will come to those which have some importance and whose rating isn't so clear. Using a 1-10 scale would make it harder to say it is 6 or 7, but easier to put as a 13 or 21.

By the time we have provided those items ranked at 1, 2 and 3, we will re-rate what we have left and all those 13 or 21 items may be better understood allowing them to be either upgraded or downgraded. The item rated 55 may suddenly become more important and change to a 2. Alternatively, it may be realised that it isn't actually needed any more or it is catered for in a different way.

Be lean

There is less value trying to break down and fully understand everything such as those items which don't jump out as being vital like a 1 or 2. That's not to say that there isn't value in understanding everything, but would you rather be creating and delivering value rather than building a deep, upfront understanding of items which aren't in high demand and may even be removed from the backlog later on?

No matter which scale is used, it is easier to rate things relatively, rather than absolutely and at any one point we will always have a backlog of items whose relative priority is known.

Value and cost

What I haven't mentioned is value and cost. This is down to the team to decide upon. Sometimes a team may decide that the rating itself is the business value and this will be sufficient.

At other times additional factors may be needed in order to work out a priority rating. We may wish to take into account complexity. Having this may lead to a change in priority if three simple items can be done instead of one complicated item.

Complexity and task sizing with Fibonacci

The same principles as described for prioritisation can be applied in many areas. For sizing or planning, estimates have traditionally been given in terms of time, for example x hours of work, and a completion date set. 

For agile teams however, complexity expressed as story points may be used. People are notoriously bad at sizing by use of a date because they fail to take into account all of those 'little' things that take your attention in the day; meetings, back-to-back meetings, phone calls, emails - they all carry a burden so it's easier just to rate the size / complexity of a task. The outcome will be a rated list of all items which can then be looked at relatively.

What does this mean for deadlines? Sprints have deadlines, but as part of a bigger plan deadlines and agile don't necessarily go so easily hand in hand. Deadlines need to be looked at in a different way and will be the topic of a separate blog.

Planning poker

Planning poker is a tool that can be used in order to estimate whatever it is that we want to measure. It is designed to be used in order to avoid the biases and conformance that creep in when a group are asked to decide something together.

For each item, the team will briefly discuss it. Each team member will mentally formulate an estimate. Then everyone will show a card with the number that reflects their estimate.

If everyone agrees then we move to the next item. If there is a material difference that concerns the group then a discussion can be had and cards shown again. If material differences still exist then the item can be put to one side to be reviewed later.

All members of the scrum team need to be there but others should be selected according to what is being estimated. If it's for sizing the complexity of the task to build, programmers should be there. Be aware though, bringing the wrong people can result in the team being pressured and giving bad estimates.


Scrum vs Kanban

(03/02/2020) First of all, let's have a recap of Agile software development. In very broad terms we have: A Product Owner (decides what to build) A Development Team builds it Users or Cus ... More →

The Agile Wild West

(02/01/2020) Agile is held up as the new way of doing things faster, and more in tune with the markets' demands. But it's not necessarily the pancea to solving the problem of creating software ... More →

Deadlines in an Agile Environment

(01/17/2020) Since Agile is flexible and adaptable, long-term deadlines don’t immediately fit into Agile and it was once said to me by a Product Owner that 'in agile there are no deadlines'. ... More →

Requirements or User Stories?

(01/10/2020) User stories are talked about here ( The Beauty of a User Story ) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is i ... More →

Documenting Agile Requirements

(12/28/2019) In a previous blog I discussed how to write a user story , and how to structure the product backlog . This is only part of how we manage requirements, and recall that I also rest ... More →

Scrum vs Kanban

(03/02/2020) First of all, let's have a recap of Agile software development. In very broad terms we have: A Product Owner (decides what to build) A Development Team builds it Users or Cus ... More →

The Agile Wild West

(02/01/2020) Agile is held up as the new way of doing things faster, and more in tune with the markets' demands. But it's not necessarily the pancea to solving the problem of creating software ... More →

Deadlines in an Agile Environment

(01/17/2020) Since Agile is flexible and adaptable, long-term deadlines don’t immediately fit into Agile and it was once said to me by a Product Owner that 'in agile there are no deadlines'. ... More →

Requirements or User Stories?

(01/10/2020) User stories are talked about here ( The Beauty of a User Story ) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is i ... More →

Documenting Agile Requirements

(12/28/2019) In a previous blog I discussed how to write a user story , and how to structure the product backlog . This is only part of how we manage requirements, and recall that I also rest ... More →

Shall we talk?

Lets have a conversation

If you would like to know more about how I've helped to transform some the world's biggest and well known businesses, across diverse industries in the United Kingdom, Singapore, and Hong Kong, then please drop me a line. Let's have a chat and I'll buy the coffee!

Multiple screens showing responsive web developement next to a hot drink for a meeting

Turn your idea into digital reality

Many of my clients requiring web design have been small or start up businesses and need a lot of guidance. I love these kind of projects as I feel I can be a part of a new and exciting business from the very beginning!

What do I call you?
Enter your email address
It would be nice to tell us why you are contacting us!
To prevent spam mail, enter the sum of the spam captcha
The spam captcha is: 3+4