Can a user story be a request for information? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

I'm starting with Scrum. I have read about it but as a newbie I feel uncomfortable about a lot of things.

These days my team is starting the creation of a new game. We know the key elements of the game but we don't really know how they will really work. I would like the team to spend 1 or 2 weeks brainstorming and defining how the elements work. As an example one of the elements could be a grid of pieces where user clicks the pieces to destroy them.

Can this be converted into a user story or this is not the kind of thing that is converted into a user story? I was thinking about writing the user story this way: "As a player I would like to know what am I able to do when I interact with the grid of pieces". With this requirement I could justify the time spent in the design stage of this element.

I know a user story is something that the product owner adds to the backlog to provide some value to the project. For me in the design stage this would provide value because stake holders would know exactly how things work before starting real development.

Thanks in advance.

Answer 1

A user story should represent value to an actual user, not just a part of the development process. Start with a story like "Player plays the game for a few turns" or just "Player moves a piece on the board" or whatever you think will fit in to one sprint. Include in your estimation the time needed for all team members, designers and developers, to contribute. When you've implemented that story you'll have something a real end user will care about. It will be terrible, since you're just getting started, but you can write more stories to address that in later sprints.

Answer 2

It's important to keep in mind that stories are "a reminder for a conversation" and that the product backlog is not static, but evolving over time.

Let's say you start with something relatively imprecise as "player can destroy pieces placed on a grid." No details as to what that means yet.

When you arrive at the Sprint Planning meeting, the Product Owner indicates that this is the highest priority item, and everyone agrees that the Sprint Goal will be to figure out different ways to destroy pieces. You could proceed two ways here, depending on how much you know about destroying pieces.

If you have some ideas on how that could be accomplished, you could have a quick brainstorming session during the meeting. Let's say that, as a result, you identify 3 different ways in which that could be done. The original story is then split in 3 pieces, and then the team needs to decide how many of those they could implement during the sprint. Something important to realize here is that you can consider this early implementation as an experiment that will provide you later with more information to further refine the ideas.

If you have no clue about how this could be done, you could add a "spike" to the sprint. A spike is a time-boxed experiment designed to gather information to implement another story. So in essence, you're scheduling research time and deferring implementation for later, but the research is time-boxed and expected to provide implementation options.