The MoSCoW principle

I’ve always wanted to write a spy novel: a handsome spy hero, a gorgeous girl, a foreign location in the heart of an evil empire, enemies outwitted and defeated. But most of all — an attention grabbing, instantly captivating title.  Unfortunately, this is not one of those posts.  Maybe, when I cross into the myth-filled middle age, suffering a mid-life crisis, I’ll throw all caution to the wind, retreat to a secluded location and pen my critically acclaimed literary debut.  Until then, back to the real world of project management and Agile.

The MoSCoW principle is a clever acronym that can help manage project scope and customer’s expectations.  It stands for features that you

  • Must have
  • Should have
  • Could have and
  • Will not have (would be nice, but don’t count on it).

The MoSCow principle is the difference between a project focused on fulfilling a contract and a project focused on delivering business value.

In a contract-based project every requirement is a Must-have.  There is no prioritization, no compromise.  You might as well figure out the order in which you will tackle the contract’s objectives, build out your WBS and your Gantt chart, and get to it.

A business value oriented project is driven by the MoSCoW principle. (Or at least it should be.) Out of al the features and requirements of the project, generally 50 – 60% will fall into the Must-have category.  Maybe another 20 – 25% will become the Should-have features.  And the rest — you have to work with the client to figure out what they could get and what will either become phase 2 of the project, or will not be done at all.

Figuring it all out and setting these priorities is not a simple task.  In fact, figuring out the last 15 – 20% of the could-haves and will-not-haves could be very painful and even politically charged, but… absolutely essential.

What could help in the process is to assign business value to each feature.  By itself, every feature is important and carries a high business value.  The true value of a particular feature can only be understood in comparison.  When you look at what is essential for your project to generate revenue, deciding between the must-haves and the could-haves becomes a little bit easier.

Mr. Potato Head of Agile or How to fill a box

In the Downtown Disney Marketplace there’s a store called Once Upon a Toy. One of the areas inside of the store sells various loose Mr. Potato Head parts: Disney themed parts, Star War themed parts, Halloween parts — almost anything you can imagine. Some parts, like the eyeballs, are small. Other parts, like the arms, are larger. And yet others, like the hats and the shoes, are large. They sell parts by a box: pick up an empty cardboard box, fill it with whatever parts strike your fancy, and, as long the box closes, it is $20.

A kid let loose to pick his own parts may grab a few of the larger pieces, the hats and such, put them in a box and find out that there is no more room for anything else. So for 20 bucks, that kid may get 6 different parts. This is what the store hopes you will do.

A seasoned or a frugal shopper will approach the problem with a little more sophistication, strategically picking a mix of small, medium and large parts to optimize the box space. This shopper may end up with a mix of about a dozen parts or more. Not exactly what the store wants, but I’m sure they still make money.

The other day, a client, new to Agile, asked me for help to understand the concept of estimating in points and how to translate story points to hours / dollars — a common request. As I was thinking about a good way to explain points, I remembered my Disney World trips. The analogy of the Mr. Potato Head box is what makes translating points into dollars tricky. How much an Agile team accomplishes in a week, how many stories and points you get for your 20 dollars, it all depends on the level of the team’s sophistication, on their velocity.

Think of the user stories as loose Mr. Potato Head parts each worth 1, 3 or 5 points (depending on the size) and of a sprint as one cardboard box. A sprint, just like the box, can hold a finite number of parts (user stories), resulting in a finite number of points. Exactly how many depends on your teams’ ability to optimize the box space — the team’s velocity. Early in the process, they probably can only figure out how to put 6 pirate hats (5 points each) into the box, accomplishing 30 points. As they get smarter and start figuring things out, they may realize that if, instead of a pirate hat for 5 points, they get 2 medium arms (each worth 3 points), they can actually complete more. And because of the shape of the arms, 2 arms leave even some room for 2 more eyeballs (1 point each) for a total of 8 points now. So suddenly, instead of 30 points, you are getting 33 points in one box.

Unfortunately, there may come a sprint when you really want that tall and pointy Mickey’s Wizard hat, which takes up much of the box, leaving very little room for anything else. Some sprints you win, some sprints you lose. At the end of the day, your box of a sprint still costs you 20 dollars, regardless of how many parts you manage to walk away with. And if you’re really concerned with how much each size part cost after all, just look at the average velocity. But only after a healthy number of good, clean boxes of parts.

Number of hours in a sprint divided by the average sprint velocity should give you the number of hours per story point.

What do you think? Does this analogy work?

 

 

Agile does not mean fast

When people think of Agile, what drives customers’ interest in Agile is thinking that Agile will enable them to get projects don’t faster and cheaper than the classic project management. But that is not always the case.  

Agile is not synonymous with fast. The dictionary defines “agile” as “able to move quickly and easily”. An Agile team is one that can quickly and easily react to changes in project’s requirements and new ideas as the project takes shape in front of the customer. If you think of a project as a road trip from point A (start of the project) to point B (delivery of the project), an Agile team is the one that doesn’t get slowed down or thrown off course by road construction, avalanches or collapsed bridges. Agile teams don’t blindly follow the GPS. If the GPS is leading them straight into the ocean, they can adjust their course quickly enough to not slow down the project. They don’t need to stop or even return back home and plan a different route.

But all that does not imply that they will get to their destination faster than anyone else. It just means that they will get to their destination, no matter the obstacles along the way.

Such agility, however, comes at a cost. The overall trip may end up taking longer than what the GPS originally promised you because it didn’t know about the missing bridge ahead. And it may even cost more: you might need to bring an extra person with you, someone who knows the roads well. But you will get to your destination and with great road trip stories to tell.

 

The cost of Agile

 

A lot of customers want to run their projects Agile. Agile is hot, sexy and all the cool kids are doing it.

But when your customer asks you to run their project Agile, do they really know what they are getting into?

Everybody likes the advantages of Agile: the daily stand-ups, the working product at the end of every iteration, the team working on features that add value. But there is a cost and a time commitment that is not always expected or understood.

An Agile project runs on user stories. “As a website admin, I want to Create a new user”. “As a new user, I want to Register on the site”. “As a user, I want to Sign up for a course”. A well crafted Agile story is made up of acceptance criteria that defines all the business rules behind the story. If a user wants to sign up for a course, what are the rules? Can they select any course? Can they select more than one course? Can they select a course that has already started? Can they select a course that starts tomorrow and it is 9 PM today? Can they sign up if they are currently enrolled in another course? What if the current course ends before the other one begins? And so on and so forth.

Somebody has to define all these stories and think trough all these scenarios. That somebody is your customer. In an Agile project, no longer can they simply work with you through the analysis phase, wait for you to write up the spec document, approve the spec and walk away awaiting the first demo milestone. In an Agile project, the customer has to be involved a lot more, almost every step of the way as stories are being written. Are they willing to make that commitment?

The other side of user stories is that somebody actually has to write them. A business analyst or an architect has to work with the customer to think through all the scenarios and to capture them into stories that will then feed the development team. Depending on the size of the team, there may need to be multiple authors. 1 author should be able to keep up with a team of 2 – 3 developers. But once the team grows to 4, 5 or more, the developers will generally consume stories faster than 1 author can write them. And considering that the story author wants to stay at least 1, if not 2 sprints ahead of the developers, story writing becomes a full time job, which will add to the cost of the project.

So when a customer asks you to run their project as Agile, make sure they understand what’s involved. Start your project with an education session on what it means to do an Agile project, explain the time commitment on their part and the additional cost to the project. And if at the end they still want to do it, make them sign something, an Agile manifesto of sorts.

 

Agile or waterfall

Coke or Pepsi? Miller or Bud? Mac or PC? Agile or Waterfall?

When a consulting company embarks on a project, what is a better methodology to use: Agile or the traditional Waterfall? What projects lend themselves better to one or the other?

Waterfall methodology seems to work better when a project presents a known problem with a known solution. Upgrading a server, creating a time-off system, or building a submarine — all are projects that are better executed by the waterfall approach. You know the problem, you know how to solve it, chances are you’ve solved it before and probably more than once. Each project will have a defined scope, a set of requirements that must be met in order for the project to be completed: the server must be upgraded to the new version, the time off system must allow employees submit leave requests, and the submarine, well, the submarine, must submerge. There’s little room for creativity, in fact, creativity may be bad — a creative approach may cause the submarine to sink or the leave request to violate HR policies.

Unexpected problems may certainly arise in each project, but nothing that would require you to completely change your approach. Nothing that a good PM can’t deal with.

The Agile methodology, on the other hand, seems to be better suited to that creative approach. You know the problem, but you don’t know how to solve it. Building a system to allow employees take advantage of a new benefit and trade unused time off for cash or for cash donations to charity may be an example of such project, especially when the HR policy around this benefit is still being defined. Such project would not have a defined scope or a set of requirements. The requirements are going to be defined throughout the project as it is being built and features are starting to take shape, sparking new ideas and new features.

But there’s a caveat. The business owner, the client needs to know what they are getting into it and agree that their project is going to be an Agile project, a creative process focused on delivering business value rather than fulfilling a set of requirements from a contract.

 

Follow

Get every new post delivered to your Inbox.

Join 529 other followers