Waterfall with a Scrum board

Having barely survived our last project, despite numerous sabotage attempts by management to derail the Agile process, I entered the our new project’s Sprint Zero with a laundry list of problems to nip in the bud. I was unable to catch those weeds during our last project because I wasn’t around for Sprint Zero back then.

Aside for a setback or two, I think we have entered Sprint 1 in pretty good shape, but one challenge that I have had to deal with nearly each day is the slippery slope of technical enabling and technical stories.

Let’s take it from an originalist’s perspective. A story which is “technical enabling” is supposed to enable the technical team to start work on a business story. “As a team, we need to get smart on the interface to the state machine system so that we can plan what the design will be”.

Likewise, a story which is “technical” involves purely technical work and does not involve business value to your client.

The problem is that inexperienced people, undisciplined people, people looking for the easy way out, and managers will start to see various such stories written and get the bright idea that “hey, maybe we need a prototyping story for this set of pages to get ahead of the developers” or “this story sounds too big, maybe we can split all of the database work out — after all, the database work enables the rest of the tiers to get the story done”.

Or even worse, one we heard from our illustrious PM: “a story should only take three to five days and tasks should be no longer than 2 to 4 hours each”.

Believe it. If you let in one exception, and then another, and then another, before you can realize it, you’re on your back, like a turtle, and they’re everywhere:

“As a database developer, I would like to develop the query structure for the Setup & Maintain Equipment story”

“As a tester, I would like to test stories 45, 39, 31, 81, and 43″

“As a mid-tier developer, I would like to handle and recover from cross-system transactional failures”

Welcome to Waterfall with a scrum board.

I think it is a shame that there isn’t an Agile Constitution, but I know why there isn’t. It will be said that it runs contrary to the manifesto: “Individuals and interactions over processes and tools”.

I have read that there is a purist school of thought out there, mainly the XP crowd, that takes a hard-line stance against all technical and enabling stories. However, I don’t know what those people do with situations where you have a set of related tasks that either don’t fit into a business story or span across multiple stories. These are situations where there is work to be done that falls outside of any business story’s validation.

I think we could be served by knowing when to use a technical or technical enabling story and when you shouldn’t.

Acceptable circumstances for a technical enabling story:

  • “Get smart” stories where the development team needs to learn about a process, technology, technique, and so on in order to start working on a business story
  • Technical setup or infrastructure pre-work that needs to occur before the development team has a suitable environment to begin working on a business story

I think these two criteria are fairly easily identifiable and well-defined. And then there are technical stories.

Acceptable circumstances for a technical story:

  • A set of related tasks that exceeds the scope of a single business story
  • Work that is not part of any business story’s validation but is part of the project’s validation.

    Like it or not, many of us don’t live in the ideal world. We are part of Enterpriseville, and most of Enterpriseville is either still recovering from Hurricane Waterfall, or has company-wide policies or deliverables that each software release has to provide: performance testing, UI specifications, usability testing, deployment.

  • Some work for which it doesn’t “make sense” to hold up a story’s closure. One example that comes to mind is data modeling. In our organization, data modeling is a bureaucratic process involving several meetings and revisions. I am not privy to its most intimate details, but I believe that the model must be an up-front effort.

And here we have an example of the slippery slope and why the creation of these technical stories must be scrutinized. I could be swayed to say that if the data modeling effort was incremental as opposed to up-front, then we shouldn’t have a technical enabling story for it.

I think that at the end of the day, if some piece of work does not fit in your story’s definition of “done”, then a technical story is ok.

A few restrictions:

  • Deliverables are not automatically technical stories or enabling stories unless it isn’t something that can be created incrementally and they form a set of related tasks that don’t fit the scope/validation of a single business story.
  • Technical stories and enabling stories shouldn’t be replicated as “standing” stories for every sprint, i.e. “Get Smart on Erlang, Sprint 1″, “Get Smart on Erlang, Sprint 2″. Technical and technical enabling stories are stories, and just like any other story, they must be discrete and have validation criteria.

My biggest question is: should technical enabling stories have points? In my company, the overwhelming consensus is yes. I recognize the fact that in a sprint with both business stories and enabling stories, there has to be a way to include the time and effort spent on enabling stories in order to avoid over-commitment. That’s a topic for another time.

But since when do we follow the overwhelming consensus here?

I say they should not because they aren’t actual work. And since they aren’t actual work, they should not contribute to your team’s velocity. And if, God forbid, they end up contributing to your velocity, like they did on our last project, you will end up with an inflated velocity.

“OK, so last sprint, which was mostly technical enabling, we completed 200 story points. So we can load the front burner with 200 story points of actual work.”

Three weeks later…

“You damn lazy developers! You only have 102 points completed and the sprint review is tomorrow.”

My teammates have told me that even though we are sizing the enabling stories that we won’t count it towards our velocity, which is fine with me. But then why are we sizing them at all, then? The only purpose of story points is to determine a velocity so we can roughly know how much the team is capable of in a given sprint.

So why are we doing it?

Managers. Managers are insecure, by definition, and feel like they need to claim credit in some way. Never mind the fact that a flat line for a sprint of enabling stories is actually an accurate reflection that the team isn’t doing actual development work.

On a side note, if you must estimate enabling stories, try as much as you can to estimate them in comparison to business stories you have completed in the past. This will make it as accurate as possible.

On the other hand, I think technical stories, which include actual work, are ok to estimate because they involve actual work. And I think there is a fine line to walk as far as how much implementation should go into these stories before you begin to slip into Waterfall.

Anyway, don’t do it. It isn’t worth it. You’ll end up fighting your management to get the project done. Oh wait, that’s going to happen anyway.

Announcer: You’re reading the EIP web-ring.

3 Responses to “Waterfall with a Scrum board”

  1. First think I would check if velocity drops from 200 to 102 is the correctness of the estimations. Not if the developers are lazy.

  2. The root problem here is that user stories are being used as trackable units of work. While this is a common enough thing to do in Agile and certainly an essential tenant of Scrum, it’s not entirely a good idea.

    In a Lean software system, work items are tracked. User stories flow only as a result of the flow of their work items.

    This allows technical and non-technical work items to be done as needed. And perhaps most importantly, it doesn’t force the description of necessary technical work to be phrased as a user story just to get it into the work schedule.

    The purist premise that you mentioned isn’t entirely unfounded. But it can implemented in a way that is somewhat artificial. One interpretation suggests that technical work should be done under the guise of non-technical work. Done poorly, this will cause non-technical (functional) user stories with unrelated technical (non-functional) work. There’s no good reason to do this.

    Another, more insightful interpretation suggests that non-functional work should be described in a way that shows the value to users and to the business. And this is, in fact, an entirely desirable approach. Doing this will force the story writer to explain why this work is valuable, and this is one of the essential responsibilities of a story author.

    A valuable side effect of all of this is that no one can just “slide” work into the schedule without demonstrating first that they understand that it is important, why it is important, and that they can communicate this importance to everyone else.

    This crystallization of clarity is an essential part of Agile work management. That said, once the role, the goal, and the motivation are communicated through a story, using that story as a unit of work management remains one of the most questionable practices in the Agile canon.

  3. I have questioned the assertions of my teammates when they say “setting up Hudson CI has no business value to our product owner”, because indirectly, it does. I suppose writing stories in such a way would be ideal, but I don’t think it will fly in my organization.

    In your comment, you first say that we shouldn’t write technical stories in a non-technical way simply to get them scheduled, and later, you advocate the approach. Is there a distinction I’m missing?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: