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.

Working on features with no value – frustrating

Few things on a project are as frustrating as being forced to work on a feature that adds no value to the immediate goal of releasing a product. When project managers who are new to product development confuse product ship date with the project deadline, you end up being forced to deliver features that will not be used for weeks or even months to come. Perhaps, not ever. That’s when you sit staring, with a twitch in your eye, at the most basic story. Those “I’d rather be <fill in the blank>” license plate holders immediately come to mind.

As a startup, perhaps, you harbor visions of grandeur, thinking of the time when you’ll be a billion-dollar company employing several hundred people in your back-office operations. But on day one, month one, even month two or three — you are not. Building features and interfaces designed to make the lives of your potential future employees easier is probably not the best use of one’s time when you’re close to launch and your current employee count is at zero.

Focus on your product. Make sure it is appealing and easy to use. Make sure that it will attract that first million-dollar customer and will enable him to do business with you. And if in the mean time your initial staff of employees has to jump through a couple of hoops and push a few too many buttons to service this million-dollar customer, well — attribute that to growing pains.




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.


The Lazy Project Manager – Ridiculously Simplified Synopsis

The Lazy Project Manager is arguably one of the better project management books I read in a while.  It does not propose to teach your hard project management skills, the ones that being a PMP is all about: WBS, costs, schedules, etc.  Instead, it focuses on some of the softer skills, the ones that we often forget about, thinking that a good Gantt chart is all a project needs.  You probably have heard it all before at some point, but the book is a short, it reads well and serves as a great reminder.

As someone said on, “Twice the taste, half the calories of regular project managers.”  And writing a simplified synopsis of it is easy — Peter Taylor provides it himself at the end of the book.

  • A project is thick, then thin, then thick again.  As a project manager, work hard at the start of the project.  Then you can rest in the middle of it and work again at the end to see it to a great close.  Kind of a variation on the old proverbs: measure 10 times, cut once; fail to plan, plan to fail.
  • Stay ahead of the game, start confidently, dress appropriately.  I especially like the dress appropriately part.  Dress appropriately for being in charge of a project, and not just for the organization you work for.  You don’t have to wear a suit everyday but being dressed a notch above everyone else won’t hurt.
  • Manage your project sponsor; know what’s in it for them.
  • Manage the project and scope creep.
  • Avoid communication breakdown.  But know when to communicate and how.  Multi-page status reports make for great documentation but, if nobody reads them, for poor communication.  As a project manager, sometimes you have to get out of your office and have a face-to-face conversation.
  • Have fun.
  • Stay calm.
  • Get the best team and retain them.
  • Don’t overload yourself.
  • And make sure to learn from each project.

I love books that can be summarized in a bullet list.

The Lazy Project Manager or Where Do I Fit In

I picked up this book by accident, looking through the top free Kindle books.  Of course, a project management book that has “lazy” in its title is bound to catch one’s attention.

If you’re looking for an advice on how to screw the pooch and be an effective project manager at the same time, this book is not going to teach you anything.  What it will teach you though is how to stop being one of those project managers who are always busy and yet accomplish little.  Instead, follow the 80-20 rule, focus your attention on what is really important and learn how to use resources available to you.

It is a hard lesson to learn.  If you’re used to being the doer, relying on yourself and delivering results, habit of doing the work yourself is a hard one to break.  To this day I have to remind myself to delegate.  Instead of piling yet another project on my plate (Oh, I can take a look at it tonight), let someone else take care of it.  It will get done and will free you up for other things.

The book is a quick and entertaining read.  Well worth its Kindle price of a whole big ZERO.

What caught my attention is this chart.

Now, I know that I am lazy.  And a few people have told me that they thought I was smart.  All of that makes me wonder.  If I believe the chart and if I believe those people are right, then…  I know how to be successful through efficient use of resources.  Just have to keep reminding myself that I’m lazy enough and I’m smart enough to be successful and to delegate.

And what about you?  Which quadrant do you fit in?


Reminded of some simple truths

It is always easier to find negatives than positives. It is easier to find something bad to say than something good. People like compliments, focus on the positives and find a way to point them out. This is really hard. Specially in IT. All our training — all the years in school and on the job — we’re taught to look for problems, to focus on them, to fix them. We take the good things for granted, they are there, they don’t need fixing. It’s the bad that we’re interested in. But when it comes to dealing with people, that’s not the best approach.

As a project manager, as a manager, as a person, look for ways to compliment people around you: members of your team, your coworkers. They will like you better. Or they will be afraid to disappoint you and not live up to all the high praise and compliments you have bestowed on them

As a project manager working with your customers, get them to concentrate on the positives. What are the 100 good things that they liked about the project? It will make the 3 things that went wrong seem not so important.

Tell them what you are planning to do

A client calls you, the consultant, with a problem: something is not working. You, obviously wanting to help, eagerly jump into action and start working on the issue. You work your precious little behind off, it takes you an entire day or more, and eventually you do figure it out. Triumphant you call the client back to report that the problem has been solved: the issue identified, the cause pinpointed; a workaround has been developed, tested and implemented. Your client is happy, they thank you for your quick attention. You hang up the phone with a feeling of a job well done and at the end of the week you bill the client for the 8 or 12 or more hours that you spent solving the problem. End of the story? Not likely…

2 weeks later your, this time irate, client calls you to demand an explanation for the invoice that they just received, “Why did you bill me for 12 hours 2 weeks ago?” “Alzheimer’s”, you chuckle and remind the client of the fix you put in per their request to address the issue from 2 weeks ago. “If I knew it was going to take 12 hours, I wouldn’t have you do it. I could’ve just <fill in the blanks>”, responds the client. The conversation is over, the client pays but they are not happy, you think you’re being nickel and dimed and you are also not happy.

If this story sounds even vaguely familiar, then you, as many of us in the consulting world, had made a mistake of not properly managing client’s expectations. It is easy to assume that your client is wise, that he or she clearly understands the problem and trusts you as a seasoned professional to do what’s right. However, the reality is likely to be a complete opposite of your assumptions. Your client may be wise, but in this case, he simply had a pain that he couldn’t resolve on his own, he didn’t know where to turn, so he called you.

Your client did trust as you as a professional to do what’s right, the problem is that you and him never agreed on what “do what’s right” really means. To you, doing the right thing meant solving the client’s problem. To him, it meant a quick 20-minute fix or he would’ve just <fill in the blanks>. (The blanks may be anything from ignoring the problem to deleting the problem record(s) and starting over, etc. Any of these solutions would’ve cost the client less than 12 hours of your time.)

No matter how big or small of a project you’re doing for your client, whether it is an 8-hours quick enhancement or a 6-months project, it is important to define the scope of the project up front. Make sure that you and your client are on the same page. Align the client’s expectations with what you’re proposing to do and with what you can deliver within a given budget/time frame. Make sure that you’re not embarking on a 6-months project, where the client wanted an 8-hours fix.