I recently completed a milestone of assessing 250 User Stories in the role of an Agile Coach. In the past week I have gone through my review notes to organize my thoughts on what I have learned from this experience. Due to a higher focus on conversations and a bias for a ‘show & tell’ approach on Agile projects, many of my review observations were contextual. Having said that, I was able to mine them to identify certain non-contextual, generic patterns of common mistakes and improvement suggestions. I plan to share these on various forums and in my training courses with the hope that it will help Agile teams craft better user stories.
Most Agile teams still seem to treat User Stories as Requirements Specifications, i.e. as contracts between business and IT. So naturally, they expect user stories to be very comprehensive and formal. I have witnessed how this encourages an “It’s not my job” mentality. It lets the other empowered Agile team members off the hook. Due to time pressures, they abdicate their responsibility to actively participate in grooming conversations, and give more importance to their understanding or even common-sense over the written word, which can never be perfect.
Suggestion: Teams (not just Business Analysts or Product Owners) should calibrate the level of formality and detail their user stories should have to balance the timely delivery of business value with the impact of comprehensive documentation on team efficacy. I have conclusive evidence that teams have been more successful when they relied more on conversations and collaboration than on documentation.
I would be a millionaire by now if I had a dime for every time someone justified a delay in story completion. By stating that despite the user story lacking sufficient clarity, the team was forced to pick it up for a Sprint anyways because PO prioritized it above others. The teams did not have an objective aid to help manage PO’s expectations.
Suggestion: Teams should define Entry and Exit criteria for grooming a story.
While several teams generally use a definition of READY, most teams I have coached did not have an Entry Criteria.
Most teams decompose epics based on implementation (architectural) layers. For example, for a new page, teams might break down an epic into the presentation (UI) component, business logic component, and database component. Specialists in these areas build their piece and then put it together in an upcoming integration Sprint. This approach does not help the team validate the value delivered by the feature early enough.
Suggestion: Epics should be broken down using a ‘vertical slicing’ approach with the intention to speed up feedback loops, and catch defects much earlier. By using this ‘end-to-end’ approach, teams can decompose a feature into small pieces that slice through each of the architectural layers. The key is to slice it as narrow as possible without compromising on value delivery. This approach also mitigates technical risks, and minimizes dependencies between stories.
Regardless of the SDLC used, requirements are just a means to an end. Consequently, the structure, writing style, and level of detail in the requirement artifact should facilitate shared understanding of the solution. However, under the guise of consistency, many teams use the same template (structure, style and level of detail) for every type of story. For example, one of the teams I coached, used Gherkin format (Given When Then) to document acceptance criteria for every story. This often made stories confusing and significantly less comprehensible.
Suggestion: Be flexible. Each user story type requires certain components (type of details), and structure to help team members comprehend the requirements, and find sufficient details to complete it in the upcoming Sprint. E.g. Gherkin’s format is not the best format to document acceptance criteria for a story which deals with data exchange between two systems. Instead, a matrix can be used to provide details on source attributes, target attributes, and a mapping between them along with data transformation rules.
I regularly see stories which are much more verbose and comprehensive than they need to be. A common reason is that authors do not use visual constructs or models. In many situations the proverb “A picture is worth a thousand words” is relevant to stories.
Suggestion: To get into the habit of using visual constructs and models, initially story authors should force themselves to include at least one visual construct in every story. Of course, if it really does not make sense to have it then leave it out. With very few exceptions, pretty much any chunk of information can be expressed more visually. For example, instead of statements, multiple business rules can be articulated as a decision table or decision tree; a sequence of events or interactions can be depicted as a workflow; domain models can help explain relationships and associations between entities/data attributes, etc.
I hope you found this useful. How many of these mistakes are made in your team? Which other common, generic mistakes have you seen?
He is an avid speaker, and has presented papers at several BA forums. He particularly enjoys conceiving, developing, selling and delivering game-changing, innovative solutions that serve customer needs.
Ronak has 22 years of experience in Business consulting and IT-enabled business solutions. This includes 16 years in all aspects of business analysis including process consulting, requirements engineering, developing & delivering training, and setting up & managing Business Analysis Center of Excellence (BA COE). He is certified by IIBA® as a Certified Business Analysis Professional™ CBAP since 2007.
Ronak will be running the online course Crafting Effective User Stories which will be run in May and June 2018.