2

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?

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
3
  • There are no "time estimates" in Scrum. Also I am not sure what you mean "it's impossible to do scrum perfectly", and why is that relevant.
    – Sklivvz
    Sep 14, 2013 at 21:51
  • Of course there are time estimates in Scrum. "I am going to get this much work done in this period of time." is most assuredly a time estimate. My point about doing Scrum perfectly is that, like any project management strategy, it's easy to fall into that rut of "Are we doing Scrum right?" If something like Scrum, but not exactly Scrum, works for your organization, then do it, not Scrum.
    – Jonathan Rich
    Sep 16, 2013 at 14:05
  • A time estimate is "it will take this long to do this thing", but that is not done in scrum. In scrum the time is fixed, never estimated. The team ultimately only has to estimate what stories are done in a fixed time frame. This is not a time estimate, it's a work estimate. You have certainty on the "when", but not on the "what".
    – Sklivvz
    Sep 16, 2013 at 15:33
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!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.