User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality.  That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!

All three concepts are important in order to use the concept of user stories in a dynamic environment where agile and lean work is pursued.  An example is helpful to see how a user story hierarchy, flow, and states fit together.    In the following example, we will follow an automotive example to highlight the user story hierarchy, how the item impacts the user story flow, and which user story states apply to the hierarchy.  (more…)


Some states are entrances!

User stories are a way of stating requirements.  Ron Jefferies coined the meme, the Three Cs to describe a user story.  The 3 Cs are:

  1. card,
  2. conversation, and
  3. confirmation.

The idea of a card was to keep the user story short to avoid making the requirement overly complex and to avoid analysis paralysis. Because the card was a short statement of the user story, conversations are required to expose the nuances of the user story (note: nowhere does it say NOT to document your conversations. If someone tells you not to document your conversations, forget them!).  Finally, the third C, confirmation equates to testable statements that allow the team to know when the user story is satisfied. User stories might begin as nebulous statements, however, when groomed, a well-formed story provides strong guidance on the business need to be addressed.

User stories pass through four basic states. (more…)

Scrum of Scrums are about the conversation!

The purpose and composition of a Scrum of Scrums (SoS) have been discussed in detail in earlier blog entries.As a means to scale, SoS has been leveraged as a structure for teams to coordinate and plan activities between each other.  The SoS is a platform for conversations such as negotiating access to a capacity from a team with specific skills or reminding everyone that you are refreshing the test environment in a few hours. The pattern of getting people together to coordinate with a structured approach in a time box is a powerful tool. That is why the base pattern has been tweaked and leveraged for many other purposes, some of which stray away from a few basics prerequisites:

  1. You have to have more than one team. It is difficult to coordinate if no one else is involved.   Just because you are doing Agile or Scrum does not mean that you need to leverage a Scrum of Scrums. Don’t think this has not happened.
  2. Participant teams need to interact with application or capability level.  Holding a Scrum of Scrums that have no functional or capability connection will devolve into a status meeting or worse.
  3. Participants need to have a valid reason to plan and coordinate together.  Even if participants share an application, project, technology or capability, they still need a reason to plan, coordinate and negotiate together or the SoS will be a status meeting.
  4. Participants must trust each other.  Without trust no real communication is possible.

A Scrum of Scrums is not a status meeting — the world does not need more status meetings. (more…)


Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)


Logistics Are Part of All Meetings

Planning meetings are not terribly glamorous.  They are, however, an important first step in effectively delivering value for any sprint or increment.  I have developed a simple checklist for preparing for a planning meeting (we will explore a simple process in the near future).  Agile planning events couple the discipline of saying what will be done and then delivering on that promise with the need to embrace the dynamic nature of development and maintenance. (more…)


Map of the Fredrick Half-Marathon

A product roadmap is a powerful tool.  Roadmaps help link products and services to the strategy, objectives and key results.  Roadmaps are directional, answer the question of where we are going and why.  Roadmaps are powerful – unless they are messed up!  There are four common mistakes that will reduce the value of a roadmap. (more…)


A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.   (more…)


Next Page »