Bad Stories , Bad Results !!
Amit Mahajan
Technical Product Owner | Associate Product Manager | SAFe Scrum Master | Business System Analyst | Solution Design & Implementation | System Integration | Solution Architect | SAFe POPM? | PSM1 | AWS Solution Architect
An Agile user story is used as an artifact to spark a conversation that describes a functional or non-functional requirement to be implemented irrespective of a specific tool (i.e JIRA, Rally, etc.) that has some business value. The most commonly used story writing format is as :
As a < role >
I want to <business requirements >
So that < business value >.
User stories are vital components in various Agile frameworks such as Scrum, Kanban SAFe, and Extreme programming. When written correctly, they provide understanding to the Agile team to view the requirements/solutions they deliver from the end-users perspective.
If written poorly, such artifacts will impact business value and make it inconsistent, difficult to decompose into smaller units of business value, or missing altogether putting requirements or programs at risk.
Below are some common mistakes to look out for that will help you to write effective User stories :?
领英推荐
Not knowing the end-user :
Often stories are being written without consideration or knowing role who is going to use the value provided by that business functionality. The overly vague role being used these days is: "As a user" and its synonyms which do not pass on enough information about end-user .
"So That" is a powerful word :
User story should describe Business requirements before the "so that" phrase. When we capture business requirements after "so that" rather than business value, a team might miss that. A bad User story contains complex or multiple statements in this "so that" section.
Introducing Developer as a user :
Poorly written User stories will eventually help you to achieve waterfall expectations in an Agile way. Often team ends up writing stories that contain "developer" as end-user, which only helps achieve design or technical requirements, and has no business value. This leads to small waterfall sprints negating the purpose of using the agile framework.
Conclusion :
Identifying common failure patterns in written user stories helps to spark the right conversations without losing focus on business value.