Breaking Down Projects into Stories: How do you eat an elephant?

Have you ever tried to eat an elephant? What about a large chunk of meat? What is the result?  I usually choke, gag, and needless to say things don’t flow so well.  What does that say about me? Am I lazy? Am I slow? Am I obstinate?  No, it says I have limited capacity on what I can swallow.  Is that bad?  Absolutely not.  It is what it is. So, how do I eat an elephant AND do so within my limitations?  I break it down.  I cut it into small individual pieces that are not greater that my capacity.  What do I get as a result? A good experience (no choking and I enjoy the food) in addition to even flow in my system (manageable).

Now, that I have described the reason why breaking things down can be valuable, we are going to get a better idea how to do just that.  This article is focused on digital consumer experiences and bringing those to life.

First, we need the business to identify the need (aka, the WHAT and WHY).  Next, we need the consumer experience folks to envision the solution for that need.  This may require user flows, usability testing, concepting, mockups and wireframes or all of the above.   Additional considerations may be technical architecture and maintenance or service needs to support the result.  Once this is complete, it is time to turn the vision into prioritized, actionable stories.

Let’s have a vocabulary lesson before we get started.  First, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do.  The goal of a story is to provide value to the end user.  Stories can build on each other but must be independent.  MMF stands for a minimal marketable feature.  A MMF is made up of 1 or more stories that provide a small, releasable piece of functionality. In other words, while the story must provide value, it may not be enough to be releasable. An MMF is value that can actually be released. Multiple MMFs can make up a release.

So, how do you start?  Ask yourself a few questions….1) When the user walks up to the system, what is the most important functionality to the user?  Example answer: The value is in creating a personalized product that’s part you and part Hallmark.  2) What’s the simplest thing the user could do to accomplish this? Example answer: Deliver a card with a single photo and one personalized text area.

Then you need to determine what the first minimal marketable feature should be.  For example:  Deliver a card with a single photo and one personalized text area to a recipient.  Then write down story titles that make up the MMF.  For example, story titles could be: 1) Deliver an empty card to the recipient which requires a) collecting the recipient’s address and b) sending that data to fulfillment system; 2) Deliver a card with a single text area; 3) Deliver a card with multiple text areas; 4) Deliver a card with a front photo; 5) Deliver a card with an interior photo?  What about informing the customer when the card ships?  Is this another MMF or part of the first one?  That’s a business question. Is it absolutely necessary to inform the customer when it ships? If it is, then it should probably be part of this MMF. From a technical perspective, you could err on the side of creating smaller MMFs to facilitate more rapid progress by the development team. There’s an excitement to completing an MMF that encourages the team and keeps them actively engaged. The business can always decide later not to release the product until the MMF with notifications is completed.

Now that we clearly understand the consumer value and priority, we can define the story more…ie more than a title.  There is a general pattern for defining stories written in narrative form… As a <user>, I want the system to <do something>, so that I <get specific value>. This clearly articulates the what and why of the solution.  But how do we know when the “what and why” have been successfully met?  Glad you asked…we need acceptance criteria for each defined story.  A “BDD style scenario” called  Given-When-Then can be used.  For example:

–  Given I have entered my recipient address

– When I click proceed to checkout

– Then the data will be sent with the order to the fulfillment vendor.

How can we further define “done” on a user story?  A few ways…1) the story is ready to ship (i.e. finished and ready to deploy), 2) the story meets the acceptance criteria, and/or 3) the story is deployed into production.

Ultimately what we care about is giving the consumer value.  So, we need to release the stories to production.  But what makes up a release?  A release can contain one or more MMF.  Our stories make one or more MMF.

What makes up a release?

  • MMFs – 1 or more MMFs per release – break out together

–      Can come from multiple Features

  • Stories – 1 or more stories per MMF

–      Example – As a browser of Hallmark.com, I would like to personalize a card with one photo and one text area so that I can send a personal card to my mom for Mother’s Day.

Breaking down features into stories takes discipline and hard work. It is a different process from the more traditional functional specification approach. Story definition, along with story prioritization, maintains focus on the real value to the end user being provided by the application, rather than on individual functions that, by themselves, provide little or no value.  When you create an application based on a functional specification, you may not realize any value to the end user until late in development when all the pieces come together. Building applications based on a prioritized list of MMFs and stories means that real value is delivered early. The business, not the technical staff, can make the decision at any point in the development process about when to deploy.

Author: Leslie Maness

Leslie Maness is a project, program, portfolio and operational management professional with 8+ year’s experience in Quality and Continuous Improvement, Leadership/Management and Training, Purchasing, Contracts and Supply Chain Planning. She is a Lean/Agile coach for the group she works with each day. A curiosity for learning continues to drive Leslie to study and apply new techniques to excel process improvement each and every day.

1 thought on “Breaking Down Projects into Stories: How do you eat an elephant?”

  1. That is too awesome. It’s been so long that I read that paper that I fogrot how much bullshit had been added by the CSM crowd.No timeboxes. No Scrummasters. Overlapping phases. Division of labor works well in a Type A system.

    Reply

Leave a Reply

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