I have the privilege of speaking with industry professionals from various market spaces and disciplines. Some of these individuals are more familiar with Agile than others. Occasionally, I’ll encounter one who applies Agile in a way that ostensibly makes sense. However, after chewing on the requirements and corresponding user stories a bit, it becomes clear one or more user stories (and the subsequent work to maintain them) is unnecessary.
I’m speaking of user stories that describe the same functionality while targeting different user personas. My most recent encounter with this scenario occurred when a client requested that three additional super-user roles be added to an LDAP group containing similar, pre-existing roles. Although these roles would have different ways of interacting with certain tasks, they would access the system the same way as other roles.
As a courtesy, the client created a user story in Confluence that outlined their request. I kindly thanked our client for the contribution and combined the new requirement with the original user story. As you might imagine, this prompted some questions.
“Aren’t we supposed to document new requirements?”
“Shouldn’t user stories be used to track the evolution of requirements over time?”
The answer to both of these questions is “Yes and no.” Naturally, new requirements should be documented; however, not at the cost of cluttering the project wiki space. Similarly, tracking the evolution of requirements over time is a worthwhile (if not exhausting) practice. This is not necessarily what user stories are for, though.
LET ME EXPLAIN . . .
Mike Cohn recently wrote an article titled “Don't Have Separate Stories When Two User Roles Do the Same Thing.” In this article, Mr. Cohn outlined a virtually identical situation to that referenced above. The bottom line is this: don’t have separate user stories when two [or more] user roles do the same thing.
The following user stories from the project I’m on illustrate the point quite nicely.
As a team member, I should be able to access [insert application name here] so that I can complete tasks assigned to me.
As a super user role, I should be able to access [insert application name here] so that I can complete tasks assigned to me.
Since these user stories don’t describe different pieces of functionality, they can be combined to form a single story. Such a story might read as follows.
As a user, I should be able to access [insert application name here] so that I can complete tasks assigned to me.
Although requirements are bound to evolve over time, this doesn’t necessitate the creation of multiple, overlapping user stories. Instead, this is an opportunity to refine the phrasing of a pre-existing user story. Doing so can help keep the wiki space de-cluttered and the backlog under control.
WHAT ABOUT QUESTION 2?
With reference to the second question posed by my colleague, “User Stories as a Chronicle” wasn’t a segment covered at Scrummaster training. Although user stories are bound to evolve as new requirements are discovered, a preponderance of outdated user stories isn’t likely to add much value. At least, this tends to be true in AVIO’s project wiki space where user stories are recorded. However, tracking the change of requirements over time is useful.
In order to cut down on the number of outdated user stories while maintaining a log of changing requirements, AVIO employs a change request log to existing user story pages in Confluence. This table contains a breakdown of a change request and a link to the JIRA ticket created to address that updated requirement. Although this modification to our user story pages in Confluence might not work for everyone, the concept can be applied to virtually any practice.
Fewer user stories in a project wiki space is added value. If not properly tended, user stories could create confusion rather than what they are written to accomplish — define business requirements clearly. When multiple user stories describe the same functionality and that functionality is accessed by multiple users, consolidate the stories to save space and potential headaches.
Riding on the coattails of the above suggestion, when a client insists on using user stories to chronicle changing requirements over time, consider adding a “Change Request Log” to the user story. This compromise seems to work perfectly in that the integrity of the user story itself isn’t diminished while providing the desired transparency requested by the client.
What modifications have you made to your user stories to satisfy client expectations?
How have compromises like those mentioned above helped (or hurt) your view of Agile?