First things first, nothing in Agile requires the use of user stories. They aren’t required anywhere. They are a tool, Agile doesn’t really define tools. Tools are useful only when they are useful and not hindering your progress or driving you insane trying to use them.

User stories are nice because they are simple and easy to use. They aren’t features, they aren’t tasks, they aren’t requirements – they are only descriptions of your requirements or features. They just need to be understood.

When a user story’s sole existence relies on a management requirement – it makes things very un-agile. Then it gets decided by the higher level powers (totally opposite of empowering the team) how the user stories should look and what their function will be. Next thing you know, developers are being handed user stories with nothing on them explained to them and they had no input in creating – meanwhile, someone creating the user stories is trying to get a master’s degree in their creation working to craft them just precisely to the properly accepted format.

Who cares if you follow the proper accepted format? Such a thing doesn’t really exist anyway – there are suggested formats and common formats – but not a proper and officially accepted format. The only proper format is the format that works for your team. Agile doesn’t require them, Scrum doesn’t require them. Someone (I don’t know who) made them up because they were easy and probably pretty quick. They can help keep the focus of the user in mind while creating the product. Requiring that they are used in Agile has the immediate effect of making Agile less agile, and only keeps the management in mind while creating the product.

Who cares if it is a little bit on the large side? Who cares if you don’t use them as long as there is a common understanding of the necessary requirements? I have provided my general tips on creating them here, you can also learn how to split user stories here. but if they don’t make sense to use then don’t use them or you can even use them differently. Adapt them to your needs and understanding. Keep things only as complicated as they need to be – any more than that and they become too complicated. Creating them should not be a longer process than creating the actual product. You shouldn’t have to spend months researching how to do them just right. You are doing it wrong if that is how you are doing it.

A general user story format – use them or don’t, but worry more about what works.

As a manager, I want to be able to total up sales at the end of the week so that I can produce my sales reports

Acceptance Criteria:

• Allow for a date range entry with a single button to grab reports between the specified dates
• Include sales related information for each employee under the manager logged in
• Include this feature for all sales managers only

Who cares if it is not phrased in the typical format shown above. “We need to be able to total up sales at the end of the week so the sales managers can produce sales reports” is more than adequate.

So you need to shave one down because it is too large to complete in a single iteration, maybe you should ask your developers for help in understanding the actual requirement (or adapt your iteration – why freeze the iteration duration based on a decision made a year ago?). Nothing about user stories should take more than an hour to understand. Nothing about applying that knowledge should take days obsessing over.

Books and Educational Material on User Stories

Reflection

I am a fan of keeping things as simple as you can, as long as it still works well. Overthinking things, adding too many rules and processes and restrictions, they just add complications. Things will be complicated enough without adding additional complications that can be avoided.

A “properly” crafted user story isn’t going to make you more or less successful. How well a task is understood might, but not a user story.