Cuttable Scope

Note: This article is updated at Cuttable Scope.

Early on in my Program Management career, I ran into challenges around cutting scope.

The schedule said the project was done by next week, but scope said the project would be done a few months from now.

On the Microsoft patterns & practices team, we optimized around “fix time, flex scope.”   This ensured we were on time, on budget.  This helped constrain risk.  Plus, as soon as you start chasing scope, you become a victim of scope creep, and create a runaway train.  It’s better to get smart people shipping on a cadence, and focus on creating incremental value.  If the trains leave the station on time, then if you miss a train, you know you can count on the next train.  Plus, this builds a reputation for shipping and execution excellence.

And so I would have to cut scope, and feel the pains of impact ripple across multiple dependencies.

Without a simple chunking mechanism, it was a game of trying to cut features and trying to figure out which requirements could be completed and still be useful within a given time frame.

This is where User Stories and System Stories helped.

Stories created a simple way to chunk up value.   Stories help us put requirements into a context and a testable outcome, share what good looks like, and estimate our work.  So paring stories down is fine, and a good thing, as long as we can still achieve those basic goals.

Stories help us create Cuttable Scope.

They make it easier to deliver value in incremental chunks.

A healthy project start includes a baseline set of stories that help define a Minimum Credible Release, and additional stories that would add additional, incremental value.

It helps create a lot of confidence in your project when there is a clear vision for what your solution will do, along with a healthy path of execution that includes a baseline release, along with a healthy pipeline of additional value, chunked up in the form of user stories that your stakeholders and user community can relate to.

You Might Also Like

Continuous Value Delivery the Agile Way Experience-Driven Development Kanban: The Secret of High-Performing Teams at Microsoft Minimum Credible Release (MCR) and Minimum Viable Product (MVP) Portfolios, Programs, and Projects

Comments

• Anonymous
  September 16, 2014
  Hi J.D, Well said, as always. Wondering if you have a blog to describe the similarity and difference between user story and system story? How to define a "system story"? Thanks, Kevin

• Anonymous
  September 16, 2014
  @ Kevin -- Thank you. Unfortunately, I haven't really covered System Stories, even though I worked deeply with them for years (especially for performance, security, and architecture work.) That said, you can think of "System Stories" like "User Stories", but the actor is   a back-end process or API, etc. vs. a typical end-user. System Stories will be increasingly important when it comes to writing stories for Internet of Things (IoT) scenarios, such as: "As an intelligent agent, I want relevant, reliable, and timely sensory data so I can respond with correct commands." In practice, I optimize writing for User Stories wherever I can because it's easier for stakeholders to relate to them, and to empathize where there is human interaction.  When it's machine interaction, eyes tend to glaze over.

• Anonymous
  September 16, 2014
  I like how you have built on Minimum Credible Release here

• Anonymous
  September 16, 2014
  @ Dragan -- I think a lot more projects would be successful if the project team has a great vision for the MCR, a great view of incremental value in the form of additive stories, and cuttable scope.