part 1 complexity - agile project management training and ... · you must take this or you will not...

Complexity:

Must have– it must be delivered; the solution won’t work without it;

should have– it really should be delivered; although it may have an acceptable workaround;

Could have– it would be great if these are delivered but these are less important than Musts and shoulds. Coulds are sometimes called ‘nice to haves’;

or a Won’t have this time– as you may expect these will not be delivered this time!

Part 1

MosCoWing project requirements allows you to deliver on time by being flexible with your features. to be streetwise with MosCoW you need to follow some basic rules.

10/10 times this is how it works:

A requirement is either a:

100% Must haves?When MosCoWing it can often feel like everything is a Must – but in reality this is hardly ever true!

Note to self! Make sure there is a common

understanding of what ‘this time’ means.

does it mean ‘Won’t have this Increment’

or ‘Won’t have this project’?

MoSCoWing enables you to deliver on time whilst protecting the quality of the solution. By agreeing what is important, you can flex requirements to deliver on time.

Therefore a way is needed to prevent too many requirements being prioritised as Must haves.

To do this you need to ask this question: Is the requirement really a Must? Are you saying without the requirement you don’t want it? Are you saying that it won’t work without it? Are you saying this isn’t a business case without it?

Worked ExamplePacking to fly on a foreign holiday

Must have – Valid passport/ID. You Must take this or you will not get on the plane.

should have – T-Shirts. You should have packed them but you could buy some once you are there.

Could have – tour guide/book – it would be nice to have before you get there, but it is not as important as your passport or T-Shirts. You may even get a free one when you arrive!

Part 1Complexity:

top tip Don’t worry about prioritising anything as a Won’t have in the early stages either. the business isn’t going to say ‘here’s

something I don’t want’ until later on in the planning process.

Note to self! A typical project should not exceed 60% of total effort for the Must haves. this should not influence the prioritisation when initially collecting requirements.

top tipPeople over analyse MosCoWing.

do not create complicated rules

to define what a should is. Keep

it simple! Just use a collaborative

conversation to decide the

priority, with the business as the

final voice.top tip

don’t worry too much about

forcing the team to downgrade

Must haves in the early stages.

As the team goes through the

project there will be plenty of

opportunities to reprioritise.

MosCoWing in the early stages of a project

For more information please visit www.agilekrc.com

© Keith Richards Consultants and evoco.co.uk ltd 2012. All rights reserved.

Complexity:

Break down the MUSTs – get granular!

MoSCoW gets its power through ‘layering’ so deadlines are met and quality is maintained. By being granular in requirements, you gain more flexibility.

By prioritising requirements at different levels they can be linked to the different levels of timeboxing. Those levels are: the Project level, the Increment level and the Development Timebox level (the lowest level of control).

WORKED EXAMPLE

Financial Status Reports (MUST) ← Project Level

Monthly Sales Report (MUST) ← Increment Level

Display in US Dollars (MUST) ← Development Timebox Level

Display in Euros (MUST)

Display in Sterling (SHOULD)

Top 10 Selling Products Report (SHOULD) ← Increment Level

Display units sold (MUST)

Display units sold by day of the week (COULD)

Year-to-date Sales Report (MUST) ← Increment Level

Sales by country (SHOULD)

Sales by person (COULD)

Part 2 s.

The M.U.S.T (The Minimum Usable SubseT)

The solution won’t work if a MUST have is not

delivered and the name given to the MUST

haves is the Minimum Usable SubseT.

Danger!If you only deliver the

Minimum Usable SubseT this is

certainly bad news –

it means too much has been

de-scoped from the project.

This is no cause for celebration!

Top TipDo not go mad when downgrading MUSTs. You may end up with something that won’t work. If you are already below the ‘60%’ guideline, then relax a bit! If you are over the 60% guideline then you need to challenge the MUSTs. opportunities to reprioritise.

Part 2Complexity:

Note to self! All requirements MoSCoW on to this – a slight change in the project objective will affect the MoSCoWs!

9/10 rule

Effort will usually breakdown into a ratio of approximately 60:20:20 for MUSTs, SHOULDs and COULDs

How to avoid scope creep

Scope creep occurs when you do not have a clearly defined objective for the project.

What happens when my customer tells me everything is a MUST?

Customers regularly say everything is a MUST. This is usually based on poor previous experiences and in the belief that if they ask for everything they might get something.

Has the Business/Customer been • let down previously by not receiving something that was promised in ‘release two’? Has the Business/Customer • been briefed on how to decide a requirement is a MUST have?Does the Business/Customer • understand why MoSCoW is being used (i.e. to deliver on time and protect quality)?

Top Tip Write the project objective on a sticky-note with a thick marker pen! It keeps it succinct… and get everyone to agree and understand it (especially the Business Sponsor!)

Being Streetwise leads to effective prioritisation but sometimes there are wider concerns that need to be addressed up front. It is best to get all of these concerns understood at the start using MoSCoW.


Top Tip

You MUST get the MUSTS

below 60% of total effort -

you really MUST

Cool tool Get off to a quick start by using a simple 3 column prioritised requirements list for MoSCoWing – add further columns as you wish.

(ID, Requirement, MoSCoW)

Danger!The 60:20:20 ‘rule’ is only a guideline – DO NOT force these figures – just MoSCoW each requirement on its own merit and see how it goes.

© Keith Richards Consultants and evoco.co.uk Ltd 2012. All rights reserved.

Complexity:

The power of the WON’T have

WON’T is a negative word but it can have a positive effect by managing expectations. A collective (business driven) decision needs to be made to downgrade a requirement or task to a WON’T if a timebox is behind schedule. The WON’T have also stops those requirements creeping back in.

Stopping Feature Bloat

By clearly stating the project objective (describedin Part 2) we can help the business to stop ‘over ordering’ on what is really required. Projects often fail as ever increasing requirements are loaded onto a project until it collapses under its own weight.

Be strong and use MoSCoW. Prioritise the new requirements. Ask ‘OK, if we add this what are we doing without?’

Part 3 s.

What happens when the business changes its mind about the delivery?

Feel happy! Change is inevitable on a project. Using MoSCoW we have structured the project so that we can still deliver. If change occurs through feedback, even better. We are getting closer to the required solution. Remember to MoSCOW the new requirements and ‘trade out’ other requirements in order to make room. Remember to ensure the new requirements need the same effort as the ‘traded out’ ones.

Who does the MoSCoWing?

The project team does - but the business has the final say. High level changes and MoSCoWing will typically be done by the Business Visionary/Sponsor. Detailed changes and MoSCoWing will typically be done by the day to day business representatives.

Top TipWhenever the business changes its mind don’t be frustrated – be happy! As long as the project objective has not changed the team will be getting a more accurate solution.

Note to self! Ask: Are you really going to need this? What is

the worst case if you don’t have it? We can use

SHOULDs and COULDs to deal with this.

Part 3Complexity:

Note to self! Downgrading a MUST to a SHOULD or a COULD gives us the flexibility to deliver on time and protect quality. Remember the downgrade is for this increment only.


When is a MUST not a MUST?

We need to think about time. Requirements might be a COULD early in the project but become a MUST closer to delivery.

There are two occasions when you can drop a MUST but it is not as simple as it sounds! …and you are not really dropping a MUST!

If a requirement is a MUST for the project and 1. you try to deliver it early – you may downgrade it to a COULD for Increment 1 – you can drop it from Increment 1 if you run out of time. This may ‘look like’ you are dropping a MUST, but really you have dropped a COULD from an Increment - it is still a MUST for the project.

When getting granular and decomposing a 2. requirement it is normal for a SHOULD or a COULD to contain MUSTs.

WORKED EXAMPLE

A ballpoint pen or biro

MUST have – an ink refill

MUST have – a ballpoint tip

SHOULD have – a plastic barrel

COULD have – a plastic topMUST have – a hole in the top (for safety reasons)

In the above example the pen can be delivered without the top. However, if the top is delivered then the MUST associated with it MUST be delivered. So if the pen top is not delivered it may look like a MUST is not being delivered but in reality it is part of a higher level COULD.


Complexity:

MoSCoWing the non-functional requirements!

Remember to MoSCoW the non-functonal requirements (NFRs) of a project. This can often help build a solution to achieve a required level of performance without creating a perfect answer.

WORKED EXAMPLE

Radar equipment

MUST work at zero degrees centigradeSHOULD work at -15 degrees centigradeCOULD work at -30 degrees centigrade

MUST be transportable by trailerSHOULD be transportable by two soldiersCOULD be transportable by one soldier

Part 4 s.

9/10 rule

When gathering and MoSCoWing requirements it is best to do this as a group. The use of Facilitated Workshops is best practice to achieve this.

Top TipAlways ask the question – is it good enough?

In the worked example it may be best for radar equipment to only satisfy the SHOULD have for operating temperature. Time and effort could instead be spent on trying to satisfy a SHOULD or even the COULD have for the weight of the equipment.

DangerConsolidating MoSCoW’d Prioritised Requirements Lists from different groups – give yourself plenty of time! It takes longer than you may think. Most of it is agreed quite quickly but some of it isn’t!

What if a group cannot decide if a requirement is a SHOULD have or a COULD have?Cheat! Just call it a SHOULD/COULD!

Can a group use the same ‘cheat’ if they cannot decide if a requirement is a MUST have or a SHOULD have?No! MUST means MUST!

Part 4Complexity:

Can you MoSCoW when working in a Customer/Supplier relationship?

Yes. Surprisingly it has many advantages over traditional contractual arrangements in that the risk caused by project uncertainty can be shared which leads to reduced costs and a more accurate solution being created.

Note to self! MoSCoW’d working needs to go into the contractual arrangements!

Note to self! Not many people know that!

Top TipIn a project environment MoSCoW is a much better way to prioritise than 1, 2, 3, …., n. This is because a project has natural dependencies and you do not necessarily end up delivering the most important features first.

WORKED EXAMPLE

If the most important feature of a project is to analyse customers buying behaviours you would deliver this AFTER delivering the feature to enable them to register as a customer.


Danger!Don’t confuse a WON’T with

something that is out of scope.

A requirement that does not map

on to the project objective is quite

simply out of scope. A WON’T have

is something that DOES map onto

the project objective but it has

been de-scoped.

Danger!Avoid 1, 2, 3, …., n prioritisation on projects – it only works in Product Environments (where you already have an existing product). Numbering does not allow you to create a Minimum Usable SubseT.


part 1 complexity - agile project management training and ... · you must take this or you will not...

Documents