Waste Archive

2

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.

9

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it’s probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it’s waste. But, since XP2002, have we learned our lessons?    Standish Group Study

Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

6

Team-Based or Value-Based

Profit LossI’m currently reading a book about Systems Analysis and Design.  In a chapter discussing Agile Methods, one of the statements really rubbed me the wrong way.
The Agile Manifesto is a set of team-based principles…
For the last 6 or so years, I’ve assumed the Manifesto was a set of “value-based” principles.  That is, at its core, Agile is about delivering value or eliminating waste.  What I like about the Manifesto is it leaves a lot to interpretation.  It doesn’t spell thing out to the Nth degree.  But, I’m very curious what the community thinks.  How would you describe the principles?

Please leave a comment.  Tell me what you think.

7

Mura Muri Muda

I had the wonderful opportunity to meet and listen to Jeff Sutherland a few days ago. For those who do not know who Jeff is, he and Ken Schwaber created Scrum.  It was really quite amazing to listen to him speak.  The topic of the talk was Using Scrum to avoid bad CMMI implementations.

Scrum and CMMI are often at odds with each other. What does each approach bring to the table? Scrum promotes the idea of focusing on the most important product issues first and supports frequent communication. CMMI brings a structure that promotes consistency and discipline to avoid waste and rework. So, why should we try to combine both approaches? Is this combination a good idea?

Mura Muri MudaThis post isn’t going to go into detail about the entire talk. Rather, there were three words Jeff said that had me scrambling for my pen. “Muri, Mura, Muda“.

The Toyota Production System identifies three types of waste (Muri, Mura, Muda).

Muri (無理, “unreasonable”) is a Japanese term for overburden, unreasonableness or absurdity.

Mura (斑 or ムラ) is traditional general Japanese term for unevenness, inconsistency in physical matter or human spiritual condition.  Waste reduction is an effective way to increase profitability.

Muda (無駄) is a traditional Japanese term for an activity that is wasteful and doesn’t add value or is unproductive.

With commercial organizations, I consistently see two primary goals:  [1] Make Money and [2] Save Money

But as you drill down into an organization, these two goals are not as obvious.  So, to address this, I rewrite the two goals as:  [1] Deliver Value and [2] Eliminate Waste

When we reach this point, muri, mura, muda come into play.  In your day-to-day activities, are there areas you can make more efficient or improve?  Do you really need to go to that meeting or can someone just email you an agenda before and minutes after?  In your project lifecycle, do you really need a 10-step process workflow or can you achieve the same goal with just 5 steps?

Here is a practical exercise:  Make a list of activities you have to do this week.  Ask yourself why you need to do each of those activities. Do they map back to the core mission of your company?  Should any of these activities be postponed until the goal is clarified?  Should you just NOT do one of them?

I have a daily meeting at 10:00.  Why?  I fill find out what the team did yesterday, what they are doing today, and what impediments they have.  My job is to help facilitate their activities and remove roadblocks.  This 15 minute meeting is a keeper.

I have an invite to the Finance Working Group meeting on Monday. Why? Hmmm.  That’s a good questions!  The meeting is scheduled for 1hr.  I know that it traditionally lasts 2-3hrs.  No invoice was attached in the meeting invite.  That leads me to believe they are going to review 500 pages as a group.  Though it’s necessary to review the invoice, this is a very inefficient way of doing it.  I will send a request for a copy of the invoice to review when I can.  I will decline the meeting invite.

Of those activities on your list, highlight which ones just don’t sit well with you.  Really listen to your gut. Are any items on your list an activity that does not directly translate into providing value?  Are any items on your list going to somehow cut into your personal life?  Are any items on your list literally a waste of time, money, or energy!?  If you can scratch any one of these items off your list, you are on the road to Kaizen (改善) (English: Continuous Improvement).

Before you accept that next task or meeting invite, ask yourself if there is a better way.


HT: Wikipedia

Like the drawing?  You can download it free at Pictofigo