Many teams use a “Definition of Done” to establish the criteria for being “done” with a user story. But does your team also have a “Definition of Ready” that defines when a story is ready for development? To get from idea to “ready”, a story (or other piece of functionality) is described in successively greater levels of detail. We call those stages Raw, Rough, Refined, and Ready.
Early in our CRM conversion project, we developed a functional decomposition diagram. This helped ensure that we had a solid understanding of the capabilities required in a new solution.
Clearly this diagram doesn’t provide a lot of detail – that’s not its mission. What it does provide is a great starting point for progressive elaboration of requirements.
The First R: Raw
My decomposition diagram represents functionality in what we would call a “raw” state. In essence, it’s just a descriptive title or phrase. Teams may also choose to accomplish the same thing by developing a story map. A story map serves the same purpose as a decomposition diagram – it takes large chunks of functionality and breaks them into smaller pieces.
Ali’s blog, The 3 C’s of User Stories: Context, Card, Conversation… and Confirmation, reminds us of four key elements of user stories: Context, Card, Conversation, and Confirmation. At the “raw” stage, we should focus on gathering just the basics—the “Card” and the “Context”. The “Card” is the one-sentence story or the descriptive title. The “Context” is where in our decomposition diagram or story map that card fits, so that we can tell where this story fits in the overall roadmap. Any additional information needed before development can begin should be deferred for later.
The Second R: Rough
- Who is involved
- What they need
- Why they need it (the value)
- Additional thoughts and ideas, perhaps in bullet point form
- Artifacts that depict the current state, like samples, pictures, outlines, or flows
- style=”margin-bottom: 2px;”Initial size estimate
- Initial priority
At this point, it’s essential to focus only on what is needed, not how it should be implemented. For example, notice that my story does not specify a printed completion certificate or sending anything via email. A well-written user story should stay negotiable, giving the team the flexibility to explore different implementation options.
The Third R: Refined
Once we have clarified and agreed upon “what” is needed for a story, we can move to the next stage of progressive elaboration: getting to “refined”. In this stage we address the 4th of the 4 C’s: Confirmation. A “refined” story has a full set of functional requirements (also known as acceptance criteria) that address all four core requirements components: data, processes, people & systems, and business rules.
Our Essential Skills for Business Analysis course covers numerous tools and techniques for describing “how” a solution should behave. To refine our user story about providing proof of course completion, we used a combination of text and models.
- Non-functional requirements detailed
- Testing approach defined
- Potential sprint identified
- Story points assigned
- Priority reviewed and agreed upon
- Initial thumbs-up from the team
The Fourth R: Ready!
Before a story is truly “ready,” the team needs to fully understand what it will take to develop and deliver it. This means breaking the work into clear tasks, deciding who’s tackling each piece, and sequencing the tasks. It also means identifying any outside dependencies—like shared services—and making sure those are engaged. At this point, the team can also confirm their estimated effort (story points). A story only gets the green light once the whole team give a final thumbs-up.
Or... is there a Fifth R?
When you’re detailing a user story, it’s absolutely critical to make sure everyone has a shared understanding of the requirements. Take awarding badges and certifications—it’s a lot trickier than it looks at first glance. I thought I had everything covered: a detailed data model, a logic flowchart, example scenarios, and more. I even sat down with our consultant and walked him through it all one-on-one. He assured me he understood exactly what was needed.
I should have trusted the little voice in the back of my head. Even though the consultant assured me he understood, something told me he didn’t fully grasp how the process was supposed to work. Turns out, that voice was right. I’ll dive deeper into what happened in a future newsletter, but for now, I’ll just say this: his misunderstanding ended up causing us some major headaches later on.
Maybe we need a fifth R for “Review”?
Progressive Elaboration Works on Any Project
In this blog, I’ve shown user stories to illustrate the concept of progressive elaboration. I chose this approach because it’s a simple way to provide small, clear examples. But if you look back to the beginning of the article, you’ll see that my starting point wasn’t actually a story map. You can apply the same idea of progressive elaboration by beginning with the processes or capabilities on a decomposition diagram instead. The key takeaway is to do things in the right order: first, understand your scope (the “raw” needs), then clarify what is needed (the “rough” requirements), follow with detailing the observable behavior and other qualities (the “refined” details), and finally, outline what needs to be done to implement the functionality (making sure it’s “ready”).
We’ve developed a new checklist to help you remember these key points. Are you “ready” for it?
All the best,
–K.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
