Is this a user story or a bug?

Question

Consider the following user story(ies) for a manufacturing management system I am building:

As a shipper/receiver I need to be able to create work orders So that we can begin tracking jobs internally

As a shipper/receiver I need to be able to update work orders So in the case of an error at incoming I can change that before handing off to production

As a inspector I need to be able to change the part number/repair scheme of a work order So in the case of a mis-identified part I can change the work scope before actually starting

These are all tasks which would take several days to implement, once the work order UI dialog had been established and the CRUD facilities, etc were in place.

Now lets say three weeks down the road, after using the prototype, and inspector comes to me and says "Receiving created a new work order by accident; The work order already existed but the part had left the building for sub-contract work and upon it's return should have been expedited past work order creation"

I might write this story out as follows:

As a shipper/receiver I should not be able to re-create work orders already in the system as WIP; In these cases the system should determine the subcon and notify me of that status so I simply pass it on through So that multiple live work orders are not duplicating each others work scope

The story sounds quite verbose...but the requirement was literally a few lines of code added to the beginning of work order creation and took only 30 mins to add. Feels odd using a story for such a request.

Better suited for a bug tracker???

My question ultimately becomes this: When I am analyzing requirements, asking questions and figuring out high level components (ie: Work orders, repair orders, sales orders, etc) I am not focusing on specific business logic or rules but establishing components.

As a user I need to be able to create and manage work orders So that we can begin tracking parts internally

Does it make sense to further break these down into atomic user stories, such that:

As a user I should not be able to receive a work order when...

Listing out the exceptions as individual stories?

To me this is where use-case and it's format for capturing requirements makes more sense...

Anyway what has your experience been? Opinions & comments welcome...

I am attempting to find a balance between the terse agile/scrum user story and the BUFD use-case approach to project planning (please leave the they are mutually exclusive argument for another topic)

Answer 1

Scrum doesn't really care about the type. A Feature, story, bug, thing, item, use-case... Anything can live on the product backlog. So it doesn't really matter what you call them.

The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be comfortable that they'll be able to finish by the end of the sprint (which doesn't necessarily mean that it's fully defined, as long as the team knows they'll be able to refine the final things during the sprint). That's the idea behind just-in-time planning and refinement. Items lower on the list may have a lot less detail as you still have time to refine them over time.

If you've chosen to use User Stories as your format, then there is generally a certain level of detail that still makes sense, then the next level is generally specified in useful test cases or acceptance criteria.

You should look at writing your acceptance criteria for your stories, the latter ones really feel more like the more detailed steps you described. Specification by Example and the "Given...When...Then..." notation would fit really well.

Only break down to a level that's needed to provide your level of forecasting and estimation. If a specific acceptance criterium would cost a lot of extra time, you may break it down into it's own story. You can always break it down at any later point in time, so only do it if you need it broken down now to set the order of implementation.

Remember that as you're refining your backlog over time, you may indeed get to a detail level that's closer to you BUFD level, but if you do, make sure that it's in some form of executable specification or in the form of test cases that you want executed, that way you don't create a lot of duplicate work.

Tools like Specflow and Cucumber can really help in doing this. Your specification is automatically mapped to Unit tests and integration tests so that you will automatically see when the work is finished by looking at your passing tests. That takes away a lot of the waste that's associated with the traditional use-case definitions. It also allows your stories to be written at a high level, then as you go into details, it's specific and easy to validate.

Answer 2

My experience; Although there is a 'bug/defect' object in RTC (the collaboration tool used to capture user-stories in my workplace) for the most part my associates tag everything as a general 'task', regardless of whether it can be considered a bug (or group of bugs) or a non-bug task.

We do have a Trac-style tool to keep track of the discovery and resolution of bugs as well, but when we take on those bugs, we replicate the description in RTC, and usually just list it as a 'task', for purposes of uniformity. It may seem counter-intuitive to describe bugs in two places, but this is useful for hour tracking if nothing else. And listing everything as a 'task' helps the higher-ups with their queries... At least, that's what they tell us.

So an example SuperEpic might be Open Source Proof of Concept, Epic could be Email app on Android, the story would be Composing and Sending, and a task would be Compose screen should show recipient instead of sender.

With regards to your use case... Is it a bug? Sure. Is it a user story? It looks like one. Why not both?

That's my opinion, anyway. But you asked for it!

Answer 3

First, I think that the use of the term "bug" is a bit off. There are some questions here on Programmers about this (1, 2, 3). Generally, the word "bug" refers to a defect in code. The software does not do what we expect - it crashes, it produces incorrect results, or something along those lines. I prefer to use the word "defect", and this other answer suggests "error" as the correct term, when it comes to discussing a broad categories of issues that arise in the development process.

Rather than trying to classify your change as a unique user story or a bug, I'd classify it as a defect in your original user story. Your original user story or some aspect of it, such as the acceptance criteria, the task breakdown, or perhaps just a breakdown in communication that lead to a misunderstanding - regardless, it seems like the activity of gathering and decomposing the requirement was the issue.