It’s not what you Scope but what you don’t Scope

The following post was originally published on an internal blog on Aug 15, 2013

“Music is the space between the notes. It’s not the notes you play; it’s the notes you don’t play.”
—Miles Davis

This quote came to mind recently when I was reading an article on the Agile Warrior blog. The post talks about a tool claimed to be developed at ThoughtWorks called the Inception Deck. This tool provides 10 questions to ask at the start of your project to set it up for success. Think of it as a process to gain clarity on why you’re doing the project when chartering and making sure you have the right people and objectives in place.

Although this tool maybe more applicable to an Epic or high level programme management there was one point that struck a chord with me and something which I think we overlook when planning a story in a Sprint.

Something I have seen reoccur are bugs being raised or Stories being rejected due to a confusion or a lack of cohesive thinking on what a feature should and should not do (Its Scope). We all approach the story definition with a range of assumptions and these assumptions are often around what the feature should and should not do and here in lies the challenge.


How do you remember to write down everything a feature should do?

One of the ways in which we can do this is by pining down the “Can Do’s” by defining the “Can’t Do’s”. By doing this we set a perimeter, defining the boundary, making it clear where the “can do’s” end and the “can’t do’s” begin. When we plan a story or define scope it’s not necessarily what the feature can and can’t do but what should and what should not be in scope. After all, if everything else is fixed, scope is the one thing that can be flexible. What aspects are you planning to change in the given piece of work? The Inception Deck describes this process as below.


Saying yes is easy. It’s saying no that is hard. The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project. Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow. Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.”


The idea is that you draw 2 circles, 1 for IN and 1 for OUT (of scope). During the discussion people pitch in elements of the feature that they think are relevant and you place them inside one of the circles. If there are area’s or elements that are unknown or are a risk you can place them outside of the circles as a reminder that these need to be followed up on.


I thought this was quite powerful and useful for Story Kick Offs or Story Planning. I can remember times where we have wasted time replicating, repeating and raising bugs in area’s that we never meant to be changed and after a conversation around a pink sticky (for Story defects) on the board the following day, agreed that it was never in the scope of that story. This was clearly a form of waste which we could have prevented by communicating more clearly.

This aids in supporting Mike Cohn‘s 3 C’s of story writing:

  • Card
  • Conversation
  • Confirmation

The realms of what is not in scope are potentially infinite so there is still a level of assumption or rather common sense involved. However, writing this down and making it explicit appeared to be a much better communication of what we were setting out to achieve within a Story. If you decide to give this a go let me know how it turns out and what improvements or tweaks you made along the way to improve it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>