6

I have a User Story that contains a bunch of tasks, similar to this:

User Story: Fix any broken JavaScript in CMS

  • Task: Find and fix broken JavaScript in content
  • Task: Find and fix broken JavaScript in code base
  • Task: Find and fix broken JavaScript in static files
  • Task: Find and fix broken JavaScript in library
  • Task: Find and fix broken JavaScript in catalog files

So I have a bunch of tasks to go through some code and files and fix some JavaScript. Let's say that all of the above tasks cannot be completed by me in a 2 week sprint.

How do I split this up into multiple stories? The tasks can be completed in any order and are not dependent on each other at all. So there is no logical way to sub-group them. Would I just do:

User Story: Fix any broken JavaScript in CMS (part 1)

and

User Story: Fix any broken JavaScript in CMS (part 2)

That seems like a poor way to manage this. What is a better approach to this kind of problem where tasks can't be grouped any better but you still need to split the story up?

Improve this question
3
  • A single User Story should never exceed a single Sprint. See the more comprehensive answer below.
    – Todd A. Jacobs ♦
    Commented Jan 13, 2016 at 23:30
  • 4
    to be rather pedantic, these don't seem to be user stories - generally a user story follows the format of : mountaingoatsoftware.com/agile/user-stories As a <type of user>, I want <some goal> so that <some reason>.
    – G.H
    Commented Jan 14, 2016 at 9:11
  • Long story short: Large scale eCommerce platform where portions of one-off page JS is put in via a CMS since it doesn't require a code release. But that is just an example.
    – Jake Wilson
    Commented Feb 20, 2017 at 23:10

3 Answers 3

Reset to default
9

Use INVEST for Story Definition and Sizing

You are struggling with decomposing your work because your stories don't follow the INVEST mnemonic. In particular, the tasks you've listed aren't testable. How could you possibly tell if you've successfully completed "[f]ind and fix broken JavaScript in catalog files", or estimate the amount of work involved?

Like test-driven development in general, the best user stories should describe behavior. For example:

As a user,
I expect the JavaScript on the catalog page to rickroll me
so that I can be annoyed and less productive.

Now it's clear what the developer needs to work on, and (more importantly) how to validate that work. You have described testable behavior rather than hand-waved the scope, the expected behavior, and the testable success criteria.

Lumping Related Items

Stories should be granular, but not ridiculously so. If you have a lot of related fixes, you can lump them. For example:

As a web developer,
I want to fix the rickroll.js logic on all 27 views
so that I can irritate all customers regardless of entry page.

Again, this defines testable behavior, has a clear and measurable scope, and provides enough context to enable the team to estimate the work involved. Whether you should have individual stories or lump them together will vary based on team capacity and story size, but at least now you have options!

Improve this answer
4
  • 2
    As a developer, I think stories that begin "As a developer I..." are pointless. The point of a user story is to understand the work from the user's perspective. Otherwise you had might as well just record what work needs to be done in simple terms.
    – Glen Thomas
    Commented Mar 29, 2017 at 8:01
  • @GlenThomas Despite the name, the user story format expects a value consumer to be defined, not necessarily an end user. If you have a question about this, please open another question as comments are not for extended discussion.
    – Todd A. Jacobs ♦
    Commented Mar 29, 2017 at 13:09
  • 1
    Comment usage defined by StackExchange: "Use comments to ask for more information or suggest improvements". I am suggesting improvements to your answer. I don't have any questions to ask. User story definition: "User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system."
    – Glen Thomas
    Commented Mar 29, 2017 at 13:54
  • 1
    @GlenThomas Your quote regarding a story's point of view says the role should be (emphasis mine): "the person who desires the new capability, [which is] usually a user or customer of the system." There is absolutely no requirement that the value consumer be an end user. You are misunderstanding the format and the purpose of the role definition in a user story. In short, your original comment is factually incorrect, although it is a common misunderstanding because of how often poorly-written user stories misattribute the value consumer.
    – Todd A. Jacobs ♦
    Commented Mar 29, 2017 at 14:24
1

Instead of 'any' I would use an exact number, or the best would be to do an investigation in sprint 1, create issues for each problem you have found, and do the specific problems in the upcoming sprints.

My problem with the current setup is that it not specific at all. Probably they'll mean different things to two different people in your organisation.

Improve this answer
3
  • What if the investigation and the step of creating more tasks for each problem takes more time than to actually do the task itself? That seems inefficient.
    – Jake Wilson
    Commented Jan 13, 2016 at 17:32
  • For example, lets say for one task above, I investigate and find 100 places where code needs to be fixed. But the time it takes to do those 100 code fixes takes less time than it did to investigate and then create 100 individual tasks.
    – Jake Wilson
    Commented Jan 13, 2016 at 17:36
  • I'm following the 10-minute rule: If I think do it in 10 minutes, I'll do it, otherwise create an issue.
    – Zsolt
    Commented Jan 13, 2016 at 18:27
1

Personally my approach would be to do tackle the technical debt based on the functionality of the application.

For example, fix broken JavaScript (all categories) on the registration pages. Then test it (including regression testing) and then move on to the next functional area.

You will probably find that the first few functional areas involve the most work and then as you progress on a lot of the underlying JavaScript will have been fixed by earlier stories.

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.