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

Why do we keep on giving up any control over our project? It would be so easy to keep it...

I get very often shocked by the comments that I hear from supposedly very smart people. Today was no exception. I heard the following comment:

There is content we don't want to timebox, therefore there's no need to link it to any timeline...

-- Quote from someone that has direct responsibility over scope in a project (my emphasis)

This quote betrays a complete misunderstanding of the dynamics of software development, and a complete (albeit unintentional) ignorance of the market forces we need to deal with.

Here's my point: by scope-boxing a particular Feature what we are doing is effectively giving up control of it's size. Once the team is given the Feature they will work on it until it is "perfect", that means we don't have a clue when it will be done and therefore the schedule for that feature is completely unpredictable! Yes, sure we will stop development on it at some point, but will it happen before it is too late?

The advantage of timeboxing the content for a Feature (Feature must fit in a Sprint) is that we have a clear deadline at which point we evaluate if the feature is ready to go to the market! Without this constraint the team is left "alone" to decide when the feature is ready. But the team is the wrong actor to decide when a feature is ready! The product owner should be doing that work based on market intelligence, user knowledge, etc.

By scope boxing (as opposed to timeboxing) our features we are effectively giving up control of our projects!

Why is it so hard to understand this point? Where is my reasoning missing clarity?

Can you help?

Photo credit: danielygo @ flickr