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.|