0

Consider this scenario:

We develop a product which will be a channel between people that need help and helpers.
People who ask for help should provide data: type of help, address, description, photo … etc. They can select a specific helper or can review the interested helpers.

I wrote these stories:

As a person needing help, I want to be able to advertise my need to a specific helper

As a person needing help, I want to be able to advertise my need in general, then review the interested helpers

These two stories have common inputs like the type of help, helper, photos etc.

Where should I define the acceptance criteria? In both stories? Then they will be repeated for the two stories.

Also:
Do I have to define to describe the user-interface controls in the story? For instance:

As a person needing help, I want to be able to access the form where I can ask for help

1
  • User stories should be relatively independent, at least in the sense that they can be scheduled and worked independently of each other. So, these stories need a bit of refinement, because the feature goals are different. I'd also suggest that you should consider using defined actors to have a baseline DoD that can be refined or supplemented separately, but there's technically nothing wrong with repeating yourself within or between stories, when needed. – Todd A. Jacobs Apr 23 at 18:15
0

I think it's fine to repeat some of the acceptance criteria for both stories. The team may decide to complete the two stories in separate sprints in which case the repetition would make perfect sense. If they are done in the same sprint then presumably the people doing the work will understand that the two things have a lot in common.

The team should decide where to put their user interface designs. I suggest that the backlog probably isn't the most effective place to document user interface elements and if you have a wiki or similar shared resource then that's probably a good thing to use. Whatever works for the team is what matters.

To make best use of stakeholder and developer time, only document the minimum needed to get a story ready to put into a sprint. Additional details can be worked out during the sprint as and when features are delivered. Stakeholders tend to become more engaged and generous with their time and feedback once they can see a real product shaping up in front of them.

If your sprint is, say, two weeks long then I would expect stakeholders to review a maximum of two weeks worth of stories at any one time but it should probably be less than that in practice. You can use Backlog Refinement sessions to help simplify and shorten the work of Sprint Planning but ultimately stakeholder review of the working, tested feature is more important than their review of the documentation at the beginning of the sprint.

2
  • the project stories should be approved by stakeholder, which they get bored from the more details for each story, and from the other side, developer may need more details for each story. we don't know really to make the balance between developer and stakeholder – Mjd Kassem Apr 22 at 21:41
  • @MjdKassem I added two extra paragraphs on the topic of stakeholder review. – nvogel Apr 23 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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