1

We have planned to take up an user story say

As a player I want to view the game map to know current standings of my team

The sprint is for two weeks. We will be able to complete only HTML in two weeks time, this user story will take 4-6 weeks to be completed as we have a shortage of content designing resources.

How can we change this user story so that HTML completion can be considered as a done for this user story and we need to take up the integration of this user story in the next sprint?

Is it possible to create two different user stories, one for HTML and other for integration, testing, bug fixing etc?

Improve this question
0

2 Answers 2

Reset to default
2

As with all stories, think of what you need, who it's for, and why they need it. The user doesn't have to be the end user. Remember that the end goal of writing stories is to help you and your team. You don't get bonus points for making stories that fit a definition from a book. Break the story up into smaller pieces that help your team focus.

For example, a front end story:

As a developer building the game map, I need the HTML markup to be created so that I can display the map.

... and a back end story

As a developer building the game map, I need to back-end API to support fetching the game data so that I can display it on the map

... perhaps a design story

As a developer building the game map, I need to final style sheets to be developed so that the user enjoys using the map.

...and so on.

Improve this answer
11
  • +1 for this sentence "The user doesn't have to be the end user". A real lightbulb moment for me!
    – Liath
    Aug 18, 2014 at 11:47
  • wow !! i was under the impression that user story always needs to have end users ONLY
    – Vignesh Subramanian
    Aug 18, 2014 at 12:03
  • @vignesh: there are some people that believe that, but again, the point of the story is to help you. Creating a story where your team is the user still adds business value in my opinion. Don't get hung up on rules, understand that agile is about providing working software rather than strictly following the methodology.
    – Bryan Oakley
    Aug 18, 2014 at 12:44
  • I am sorry, I disagree with some of your statements. Yes, agile is about using common sense and not about blindly following rules. No, user stories are made for users and the team, not only the team, otherwise it would be called a team story. The reason why you have to fill in a user in the story is because it gives meaning to the type of user of the actual product. Developers do not use the software. And there is no business value in creating the html markup without a backend. In stead of splitting it up into different user stories, why don't you create tasks related to the user story.
    – user99561
    Aug 19, 2014 at 21:43
  • As your team is not a business user, there is no business value into creating a html mockup without backend. (There might be, if the end user uses this html mockup as publicity for the game, but I cannot make up examples for the stylesheet story and the backend). The design story you give as example doesn't make sense to me at all. Can't finishing the design be expected to be part of the definition of done? Breaking it up in user stories like this looks like it gives the user the chance to ignore the design if the want, making your team to deliver a substandard product.
    – user99561
    Aug 19, 2014 at 21:51
0

I think your question hides a bigger problem: the lack of content designing people (please don't call people resources, it depersonalizes them) seems to indicate that your team is working in development silo's.

On a recent project I worked on the same happened. We had front enders, integrators and back enders.

I was a nightmare. Although front enders were constantly busy, the integrators were not, and the backenders didn't know what to finish first. It ended up in having 40 or more unfinished stories at one point in time with nothing finished at all (beside the problems in the team, we also had to wait endlessly for stuff to be finished by another party).

We had to estimate the completion of stories just to give the customer an indication of the progress. Your question reminded me of this. Yes, we could show mockups to the customer, but as long as he couldn't use them (finished, fully documented, tested and approved), they were of no value to him.

My advice to you: when the content designing people are starting the work on a story, let them pair program with some of the others. It might cost some time in the beginning but might definitely be worthwhile the effort on the long run. With 20% of the knowledge often 80% of the work can be done. It can get some pressure of the current content designers and create a better flow in the team.

Improve this answer

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