Level of detail of a user story

Question

I am about to start User story sessions in my team. It's quite new for them and I am also wrestling with certain things. For the current project we have some well worked out wireframes.

I read a lot about the way of writing user stories. What the template should be like and about different aids like Invest

The plan is to turn them around in user stories. Lets say I have a screen where a user could edit an order. There is a lot of detail on that screen. Now when creating a user story of this story. Will it suffice to say:

As an Admin I can edit a purchase order so that mistakes typed by the user can be enhanced.

Or should i specify each detail like:

As an Admin I can resend an invoice to the customer, so he can get a copy of his lost one.

As an Admin I can review the customer order so he has detailed information about each purchase

As an admin I can remove items forma on order so that in case the customer made a mistake I can remove Items.

---

And how about the acceptance criteria. How should the be defined for a user story as such. Where do I define which fields need to be shown on an order detail page? Can this be part of the acceptance criteria?

Answer 1

Since this is tagged scrum, you likely want to defer to a more detailed user story. If you were using something like XP or FDD, you can be a bit more agile because the milestone is not time-based.

With Scrum, you really only want to define the user story enough to be able to adequately give an accurate time estimate - however much definition that requires.

It really depends on the whims of the team and the stakeholders, but if you delineate 10 aspects or subfeatures of editing purchase orders, you aren't likely going to be able to add another once the sprint has been planned, and if one of those subfeatures is involved enough (like removing items from an order, possibly), it may need to be turned into a feature with a story of its own.

It's impossible to do Scrum perfectly, however the end goal of Scrum is not to remove all ambiguity, but rather to clearly define basic functionality to remove enough ambiguity to give a mostly accurate time estimate.

Answer 2

There is no "prescribed" way to do stories in scrum, so there is no straight answer to your question, however I can give you some general advise based on experience:

1. If your team is not experienced in scrum, make the stories as small as possible. In fact, if you can make them small enough, you can substitute that for story point estimation without losing much predictability.

2. Put as little as possible in the story. Avoid designing software in stories, include only what matters to the user. Are the exact fields absolutely necessary? You better make sure they are developed: use acceptance tests. Are the fields not strictly necessary as long as a certain operation can succeed? Put the success of that operation as acceptance, instead of the fields.

3. Make sure your product owner is available during the sprint to answer question and provide details. Don't fall in the trap of having the PO only interact at the planning meeting or using the stories as a message board to the team. The PO is part of the team and must be in the team during the sprint.

Hope this gets you started in the right direction! Good luck!