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?

gnat
  • 21,213
  • 29
  • 113
  • 291
Vignesh Subramanian
  • 393
  • 4
  • 10

2 Answers2

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.

Bryan Oakley
  • 25,332
  • +1 for this sentence "The user doesn't have to be the end user". A real lightbulb moment for me! – Liath Aug 18 '14 at 11:47
  • wow !! i was under the impression that user story always needs to have end users ONLY – Vignesh Subramanian Aug 18 '14 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 '14 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 '14 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 '14 at 21:51
  • @user99561: you're saying there is no business value in having your team be productive? I don't agree, but I understand where you are coming from. The reason you don't split the story into tasks is explained in the question -- the story is too big to fit into a sprint. – Bryan Oakley Aug 19 '14 at 21:55
  • By splitting it up into tasks in stead of user stories, you at least give the impression that the story is a whole and not just expandable parts. No offense intended Bryan, I value your opinion, but I have to give -1 for your answer, as someone else got a lightbulb moment from it for reasons I do not agree with. – user99561 Aug 19 '14 at 21:59
  • @BryanOakley: As long as there is not a completely finished end product (for this story) the value for the business users is zero. I would prefer to work for more than 1 sprint on a story than to split it up into user stories with no shipable end product. Stories that are unfinished before the end of the sprint also get carried over to the next sprint. – user99561 Aug 19 '14 at 22:04
  • @user99561 -- could not agree more why not just have a story "Project Manager wants development to fit his timeline" – James Anderson Aug 20 '14 at 01:18
  • @JamesAnderson: the point of fitting stories into sprints isn't to make the Product Manager happy per se. The point is to be able to properly estimate, and one of the tools toward that end is to reduce complexity. Large stories are harder to estimate than smaller stories. If you go through the exercise of breaking a large story into smaller ones, you may very well find what you thought was a two sprint "story" actually will take three or four. Your PM won't be happy if he doesn't find that fact out until the end of the long sprint. – Bryan Oakley Aug 20 '14 at 01:31
  • @BryanOakley: making good estimations is mostly to help your business people to decide on the priority of a story. What I find more important is that by keeping stories small, they are much more finishable. This helps your team to get order in the chaos. – user99561 Aug 20 '14 at 10:33
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.

user99561
  • 334