Creating options by slicing features - #NoEstimates technique

Each feature (or story) in a product backlog contains many undiscovered options. By taking features as they are without slicing them into thin slices of functionality we implicitly commit to an implementation strategy. However, when we slice features we create options that allow us to pro-actively manage the scope of a project.

Let’s return to the IT Support Ticketing System project we discussed in a previous post. A feature like the one below will not allow us to manage the scope actively.

• As an employee I want to be able to submit issues to IT so that I can fix a particular problem that prevents me from working.

The feature above is what I would call a “binary” feature. Either the employee is able to submit an issue to IT or not. This simple feature can have large implications in terms of the amount of work required to implement it. Taking the feature above and breaking it down into several smaller features or stories will allow us to make decisions regarding the implementation order, or delaying certain parts of the implementation. Let’s look at an example:

• As an employee I want to be able to email an IT issue to the IT department so that I can have a fix for a problem that prevents me from working As an IT helpdesk employee I want to have a queue of issues to handle so that I know what items I should be working on at any given time.

By slicing the original feature in this particular way we unpacked the functionality under the term “submit issues” in the original feature into two different features: Email (replaces submit) and Queue of issues (replaces the receiving end of the submission process). We’ve potentially reduced the scope of the initial feature (no need to have a system to enter IT tickets, just send an email), and we’ve given ourselves the option to implement a solution based on standard tools. The two features we created allow for a solution based on email and a spreadsheet program with shared editing, like Google Docs.

These two stories could still be implemented with a full-fledged IT issue tracking system, but that is an option. Not a mandatory outcome of the initial feature. Slicing features into separate functional parts helps us actively manage the scope by creating different implementation options that are often implicit and non-negotiable when we have larger features in the backlog.

Picture credit: John Hammink, follow him on twitter

Waterfall leads to 90% ready 90% of the time! (the very definition of unpredictability)

One of the most common anti-patterns I've seen in waterfall projects is the "90% done syndrome". It goes like this: the project will get quite quickly to 90% readiness and will look to be on time until that point. However, after the 90% readiness point is achieved we start to see more and more delays and blast through deadlines like there was no tomorrow.

Why is that? I've spent some time thinking about this question. With Agile projects we avoid this syndrome quite effectively by managing the scope. In practice we avoid the "90% syndrome" by declining to work on the content that would delay the project but not add enough value to justify that delay. But, then some time ago the question came back to me. Why is it that in waterfall projects we have the "90% syndrome"?

The answer to that question just hit me today (a real "d'oh" moment): the reason is that we don't really know about all of the requirements until we are well into the implementation (say 70-90% into it). Therefore we will only really understand the full content of the project when we are close to the end. This, coupled with the fact that waterfall projects tend to be organized architecturally/horizontally (instead of feature/vertical sliced) leads to knowing about critical requirements too late(90% ready for a long time) and not being able to remove content (because we release the lower layers before the upper layers) to meet the schedule.

This anti-pattern is quite simple, but apparently it takes time to understand the forces at play, and most managers (including project managers) constantly miss this point...

Photo credit: striatic @ flickr

Why Apple deserves to sell many iPods/iTouch (or Why MUST features will kill your project...)

So lately I've been trying to convince some friends that they don't want to have "MUST" features in their project, rather they should opt for a force-ranked prioritization of all features that they want to deliver.

First off, I must explain this idea. You do still have a minimum marketable content for your product. If you are delivering a text editor that might include being able to write text, saving in UTF-8 or localization into Finnish (if you happen to want to sell your product there). There's nothing wrong with wanting a minimal set of functionality before you release your baby to the cruel world out there.

Having said that, there's a huge different between defining a minimal releasable content and having MUST features.

For starters the "MUST" state of mind normally leads to having MUST features that are not at the top of the list of things to do. You will say to yourself that you have to do this architectural change here, or improve the UI for another feature over there. But you will release that super-duper MUST feature even if it is like 40th on the list of 80 things, of which you can complete about 20 before the competition outruns you... Stop kidding yourself!

If it is a MUST, then it is the first on the list, no exceptions. At any point in one project there's only one and only one MUST feature -- the one you are working on! And even that can be scoped-down to suit your market-driven deadline. This is so that if your market changes, you can respond quickly and release a new product ASAP.

You will have certain features (maybe 1 or 2) that you will not be able to release without, others can be greatly de-scoped to make you release faster.

A good example was Windows XP. The first layer of the UI was great (compared to Win98/2K), but when you started digging around you saw that the second and subsequent layers were just the same as in Win2K. XP was supposed to come out faster, so they did not polish every single nob, they went for what made sense: faster OS and better looking first impressions.

Another example was Nokia's Ovi. They started with an empty website! Later they added Share.ovi.com and eventually went on to build the entire portofolio -- they understood time was not on their side!

Some people would argue that, you still need MUST features even if they make you delay a product release, that those MUST features are worth it because (aledgedly) they are so important that we could not sell the product without those. To those people I say: really? Did you know that 64% of all features in software products are "rarely or never used"? When was the last time that you used voice recognition on your windows box? Or when was the last time you tweaked all the settings available in Windows?

The fact is that we need to be "Editors" of our software products. There are very few things that make people buy our software/hardware products (Rio vs iPod anyone?), and those are the only things that make sense to build in the first place.

Now, you will hear from many companies the idea that "no, we need to build feature X before we release!". That's just dumb! While you spend precious time building those features your competitors will be laughing all the way to the bank!

For those of you that may not believe me here's an example: Windows Mobile has had most of the features that the iPod/iPhone has today and much more that iPod and iPhone don't have. However the iPod/iPhone are selling at a much faster pace that Windows Mobile, why is that?

After all Apple did come from behind and for the iPod Touch started from scratch (compared to WinMobile which is quite developed and stable platform and was already when Apple started to work on the iPhone/iPod Touch), and Apple had to develop their own Hardware! How come they provide a better product that WinMobile?

The reason is simple: Apple did not cram the iPod Touch with features, they went for the 20% that satisfy 80% of the customers and used their delivery system to deliver new features later. They did not wait on their asses until they had a similar feature-set to the WinMobile. Heck they even missed the mobile e-mail boom with the MobileMe debacle!

The reason for Apple's success was simple: release the product at the right time and put money where in pays: in top-quality marketing!

There were a couple of MUST features in the iPod/iPhone that they had to get right before their release, but the most important feature was: release date! If you are as good as Apple at marketing your products, you can even charge your early adopters extra to get basic applications that all other mobile devices already have (iPod Touch update for money to firmware 2.0).

There are many features that you would consider MUST that were never implemented in some products, but those products were successful anyway! (3G on the iPhone 1?) The people designing those products understood that what made their products successfull was not that extra set of features. It was a completely different set of constraints. In the consumer market, things like visibility (placement, marketing, channel) or price have a far larger impact on the success of the product than many (i'd say maybe even 90%) of the features that get added to those products.

When you start a project, decide which are the economic drivers for your product: do you want to hit a market on a set date? Do you want a pre-defined set of features? Do you want to use a certain channel? Ask yourself what is important before deciding to use "MUST" features. Don't shoot yourself in the foot just because you didn't spend 5 minutes thinking about what makes your product successful.