Defining The Qualified User Story

User Story

Regardless of the client I work with, the teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.  It doesn't help when they first ask how big user stories are and my first response is "it depends". It's not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn't matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn't ready to be worked.

We need to label [this] to set it appart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban.  To be clear, I'm not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.

Image Source: Pictofigo HT: Originally posted at LeadingAgile

Epics, User Stories and Tasks

I was working with a client this last week and I overheard one team member trying to explain the difference between Epics, User Stories, and Tasks.  He finally offered an analogy.

The Analogy

Epics are to User Stories are to Tasks as Rocks are to Pebbles are to Sand.

I thought it was a clever description of comparing relative size and complexity of work. But would it pass muster with the Agile Community? I figured I would send it out to the Twitter-verse and see if any conversations would result.

The result was an excellent conversation with David Koontz.

The Conversation

Though I will admit there are some challenges in communicating in 140 characters or less, it really forced me to think about what I was trying to say.  David did a really great job of challenging me to explain what I was thinking.  In tweet responses, David stated if it can fit in a Sprint, he calls it a User Story.  If it is too big to fit in a Sprint, it is called an Epic.  I have to say, if we all followed that model, it certainly would simplify things.

I find customers asking if they can call them sub-stories, major stories, and craziness like that. Customers take a stab at breaking down work to manageable chunks but when the team estimates the work, it's still too big to fit into a sprint.  To restate David's identifying criteria, too big equals epic; small enough equals user story.

David then asked me,

does Epic == collection of stories? Or some stories and some waste we should never do?

My response was,

I believe epic != collection of stories. I believe epic == placeholder of a goal or idea. Stories may result but no guarantee

The Clarification

To clarify my beliefs, I believe a User Story as merely a placeholder for a conversation.  I believe an Epic is a placeholder for a goal or an idea.  Along the way, there will be resulting value delivered and waste.

Though you should be able to map all of your User Stories (and waste) back to Epics, that's not the goal.  You don't just do tasks and then look for a bucket of stories or epics to group your efforts.

I won't say having something small enough to fit in a Sprint is automatically called a User Story.  What if you don't leverage Scrum?  What if you are leveraging Kanban?  In either case, we refer back to the conversations.  As long as your work meets your definition of Ready, I don't care what you call it.

Thank you, David, for an excellent conversation.  I hope others will join in.

Zombie Procurement Strategy

The last few weeks I have been advising a Federal Procurement team as they refine a Procurement Statement of Work (SOW).  Unfortunately, I see the existing version as being very heavy and I want the final product to be much more lean.  A perfect example is the current program has 29 documents that are contractually required to be delivered.   Do these documents provide value?  No, most of them to not.

Opportunity 1

Instead of writing the SOW with statements like "Contract holder will deliver this document" and not provide why or how it will help the customer accomplish their goals, I think we miss an opportunity.  I believe we need to advance the conversation with the potential vendors, by structuring the future work as Epics.  As long as the customer quantifies "reasonable", we give the potential vendors an opportunity to think outside the box.

As the owner of the production system, I want to be able to know the average wait time when a customer calls, so I can ensure they are receiving a reasonable level of customer service.

Opportunity 2

Rather than using practical wisdom to create a new SOW, some would rather rely on past policy, procedures, and governance, regardless of current and future needs or if they ever made sense.  I've challenged some by saying there are no procurement requirements stating that we must have these 29 documents.  One Zombie response was  "I found management plans and documents referred to in the PMBOK.  We should require the vendor to deliver all of them ".

Before I emptied a full can of Zombie Away on him, I said that wasn't the most efficient approach.  The PMBOK also says to use "expert judgement".  If you are not prepared to use expert judgement, a vendor is going to take your Zombie money and walk off with it.  All you'll be left with is an empty wallet and 29 documents.

I'm all for looking to the PMBOK for guidance.  But remember, it is a guide, not commandments.

Like the image? Find it at Pictofigo

2011 Resolutions WIP

Last night I submitted my speaking proposal for the Great Lakes Software Excellence 2011 conference.  The title of my talk is Breaking the Law of Bureaucracy. A little back-story:  One of my "Epic" stories (Resolutions) for 2011 was: As an agile proponent, I want to articulate the values, principles, and methods of the agile community to the traditional project management community, so there will be more mainstream adoption of agile.

What's my acceptance criteria for this Epic?  I must appear (speak) at no less than 4 conferences.  I must write at least 1 article to appear in a trade publication. I must publish my book (Zombie Project Management).

As you would expect, I broke the epic down to multiple (actionable) stories and prioritized them.  The GLSEC is number 2 of my 4 conferences.

Below is the abstract I submitted as part of my proposal.

Abstract - Breaking the Law of Bureaucracy

The law of bureaucracy exists in all organizations.  The larger the organization, the stronger the law. Examples of this law, in a business organization, would be those who work and sacrifice to bring value to the customer, versus those who work to protect policy, process, and procedures (regardless of use or value). The Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions.

Top-down organizations are suffering from the worst case of egoism: When each person acts to create the greatest good for himself or herself.  When the organization and its employees make decisions merely to achieve individual goals (at the expense of others), they lose sight of the original organizational vision or goals.  The law of bureaucracy can be broken, through team empowerment and altruism: From this perspective, one may be called on to act in the interests of others, even when it runs contrary to his or her own self-interests.

This talk will introduce ten characteristics of servant-leadership, to help those who currently manage others, to break the law of bureaucracy.

Like the image? Find it at Pictofigo