How many of you have experienced the following on a project? The initiative kicks off fairly well, but as time goes on it become apparent that what the customer asked for isn’t indeed what they needed. After some introspection the team comes to the conclusion they must have messed up the analysis, if only they had done a better job of understanding the need, all would have gone well. Sadly this can lead to the negative feedback loop where a team spends more time up front doing analysis, adding time to a project, only to find later on that they still didn’t “get it right”. With the project schedule growing, the business, fearing this will be its one shot to get changes to this specific capability, puts together an ever growing list of requirements, because they believe it will cost them more if they ask for it later. My experience has been that these two trends lead to a nasty pattern that can lead a team to analysis paralysis or with a greatly bloated scope. Ironically, this was done to be more efficient.

I would like to say that once a team goes Agile, this problem is solved. As we are doing iterative work now, we don’t need to know everything up front, at least that’s the theory. We can go back as many times as we want and keep improving it, right? In my experience, even if we start an iteration with an flat list of acceptance criteria, the team will frequently find additional things they want to do but can’t fit into the time box. This is not bad, but after the 3rd “improved capability X” story shows up, product owner patience has worn very thin.

Unfortunately, it is at this point, that the analysis trap can rear its ugly head. If we are doing the same piece of functionality over and over again, perhaps we haven’t done enough analysis. Maybe if we did more work up front, this pattern could be avoided. There is a grain of truth in this thought pattern, but I have come to appreciate it is a treacherous road to go down. If formal requirements gathering phases can’t figure something out properly, why do we think we’ll be able to do so in a 2-4 week iteration? So how does one balance the need for proper due diligence before taking on  story against the risk of opening up a can of scope creep capable of derailing your team’s progress?

The best approach I have found is to increment a given feature along some clearly delineated theme as opposed to a list of criteria. Building stories around a specific dimension allows the team to further constrain scope and better manage progress. Generally speaking a given function can be broken down into different smaller parts, of course the challenge is upon which dimension do you break something apart, and how do you best manage those boundaries. In my opinion, this is the real challenge. I offer to you the following techniques I have used, with varying levels of success in no particular order.

• Splitting along a technology stack: this is one of the most common practices I’ve seen, and it’s also used to break stories among different teams. The best example I can think of would be if one team is going to build a web service, and a 2nd team is going to consume it, then the two teams spend enough pre-planning time to agree on an interface and beyond that each team can work independently. It could also be applied to something like a web page, where one story is to build the basic business or data retrieval logic, and the 2nd story is to apply appropriate grouping, formatting and other presentation logic. This is one of the easiest ways to split apart larger, more complex stories, but it caries the risk that the whole really can’t be validated until the all complete. From a point of view of getting earnest feedback from your business user, this technique does not offer much value.
• Splitting by stakeholders: many capabilities are going to be used by multiple roles or stakeholders. Generally speaking, I have seen this lead to the anti-pattern that someone says, “while you’ve got the hood open for one, you might as well do what we need for some other groups too”. Explicitly drafting stories for each role or stakeholder avoids this problem and helps to delineate the scope for an iteration. If you are building a feature for role X, if role X doesn’t need a specific capability, but we suspect we may need it later for someone else, it’s out of scope. The biggest challenge I find with this technique is that sometimes people assume its easier technically to build more all at once, so they group the needs of multiple stakeholders together, thinking it will be more efficient. Much like business users giving solutions as requirements, this is a dangerous “shortcut” that should be avoided at all costs.
• Splitting based on objectives: this is a less clear distinction than by a stakeholder or technology component, but sometimes a given feature needs to achieve a bare minimum objective for now. In this case, the story is focused on that objective, once the criteria to meet that objective are met, the story is complete!
• Time boxed analysis: this is a very crude method, but sometimes it is your best hope. I had one challenge working with an IA designer who wanted 2-3 weeks to design a basic wireframe for something we needed to build shortly. After some frustrating back and forth, we finally agreed to let him work for half a day, and whatever he had at that point was our criteria for the story. Of course this wasn’t our final set of requirements for the user interface, but it got us moving towards a usable product much faster.

Ultimately, we need to remember that is our goal, to get to workable product as fast as possible. Getting basic analysis done is a small, but critical part, of the battle. The product built needs to be put in front of users for feedback. I have seen teams also fall into the trap where something is “not done”, so they don’t want to show it to stakeholders. The challenge of calling something “done” is always a difficult one. By the very nature of iterative work, rarely are we ever complete. Our goal is to keep working to build the best product with the time and resources available. We need to adjust our mentality such that there is not one final truth, but rather a constant journey towards something better. This is something that needs to be communicated beyond the immediate team, so that stake holders and consumers or our products understand that this is a collaborative and iterative process. We should not be frustrated if it takes us two or three times to get something right. Rather, we should plan for it and try to manage in a methodical way to ensure we are truly building up quality and value rather than blowing in the winds of different needs. I hope this list of techniques is useful to you and would love to hear of other ways peole have been able to break down and solidify criteria for stories.