10

We currently use JIRA to track our development work. My management wants to format and categorize everything as "User Stories," including non-software development related tasks. For example:

"As a test manager, can I perform testing of the application using only automated tests and no manual testing so that I can test the application as efficiently as possible?

Acceptance Criteria: 1. Convert 50 existing manual tests to fully automated tests 2. Tests must execute in less than 1 hour"

I want to get a sense from the community if it makes sense to use "user stories" for work that supports the software development process, is not done by the programmers, and does not directly results in deliverable code. Or should this be handled/classified differently (for example, in JIRA)?

Updated 6/7/2011 - Rephrased question to focus on "user story" term.

Improve this question
1
  • Thanks everybody for your thoughts--keep the comments coming! The above is just a [overly]simplified example since I don't yet have one as written by our management team. But based on discussions, they want to be able to measure process improvements such as "convert 100 (or some percentage) manual tests to automated tests by the end of the quarter," etc. They want to put all this in JIRA and categorize these as "user stories" as opposed to "tasks" or something else.
    – Dan C
    Jun 6, 2011 at 20:20

7 Answers 7

Reset to default
11

Yes

any stakeholder, any feature that improves the system

[let the purist downvotes begin!]

Improve this answer
5
  • +1 Just be clear on who the stakeholders are, i.e. devs, managers, etc. [Let the flamewars begin!]
    – Michael K
    Jun 6, 2011 at 16:50
  • 1
    I'm a purist, and i approve of this answer.
    – Tom Anderson
    Jun 6, 2011 at 16:57
  • I disagree but won't downvote because I appreciate your courage :)
    – maple_shaft ♦
    Jun 6, 2011 at 17:02
  • Was going to give a long winded version, but this says it all! "Maintainers" and "People working on this thing in 3 years" are valid stakeholders to consider!
    – Al Biglan
    Jun 6, 2011 at 17:25
  • Yes, for example, SaFE methodology calls them "Enablers" scaledagileframework.com/enablers
    – Luxspes
    Sep 24, 2022 at 21:35
7

"My management wants to use Agile for everything, including non-software development related tasks."

This does not mean writing user stories for every feature.

If you want to write user stories for every feature, you're not necessarily being Agile. You're just writing user stories for every feature.

User Stories != Agile.

User Stories is a way to gather and understand requirements. They can be used in a perfectly waterfall way, if you want to. Some people do this.

Agile is a way to manage projects. You can use User Stories, or not, in an Agile project.

User Stories to manage technical debt and internal tasks -- again -- has nothing to do with being Agile.

Many folks are perfectly happy adding "technical" or "support" features into a sprint without wasting time writing a fake "user story" for purely internal, limited-value-add, non-stakeholding users.

If QA doesn't get their story, how much real business loss is there?

If real stakeholders don't get their stories, the business truly suffers.

Improve this answer
4
  • I agree that "User Stories" can certainly exist without "Agile." I just wonder if the term "User Story" is good for something related to improving our development process and not for adding an application feature.
    – Dan C
    Jun 6, 2011 at 20:31
  • @Dan C: What's import is this. Your question confuses two unrelated concepts. "management wants to use Agile for everything" is totally misleading when compared with your actual question. Please clarify this.
    – S.Lott
    Jun 6, 2011 at 22:09
  • Good point. I rephrased the question and provided more context.
    – Dan C
    Jun 8, 2011 at 4:23
  • I so much agree with you that user stories do not equal Agile. User stories are just a reminder that a requirement has to be discussed and that requirement might be a feature of a system to be built, a business process to be enhanced, or anything of any nature e.g. planning a wedding. What Agile stands for is "Less documentation, More collaboration"......(please bear in mind, Agile didn't say "No documentation", it advocates "Less documentation")
    – Baba Kososhi
    Apr 18, 2019 at 21:20
2

This doesn't make sense to me. A 'User Story' in essence is just that, a user story, not a Project Manager story, not a Developer Story, not a Quality Assurance Engineer story.

On that note, software is:

  1. Definable
  2. Testable

Process improvements are open ended, and typically subjective.

Acceptance Criteria: 1. Improvement to testing 1 (by x/y)

How do you measure Improvement to testing? There is no definable contract for that.

And on an unrelated note I SINCERELY HOPE that your example given above,

As a test manager, can I perform testing of the application using only automated tests and no manual testing so that I can test the application as efficiently as possible?

... is just that an example, because there is so much wrong with this that I can't even begin to describe.

Improve this answer
1
  • Maybe having process improvements being open ended is the bad thing? I've always found the best improvements are very specific, achievable, etc. Best to make these visible and work with a Product Owner to prioritize them. The acceptance criteria given as examples are bad, but so are many feature requests initially! Let the team hammer it out and refine them. Maybe they morph to "create mock objects for external interfaces X, Y and Z" or something...
    – Al Biglan
    Jun 6, 2011 at 17:30
1

Technical Debt could be handled in a similar fashion to a user story but this can get rather ugly at times. For example, to have a story like, "As a developer, I want to have working unit tests so I can have confidence in the tests to validate if other changes break something," doesn't have a lot of value to the product owner but may well be a good idea for the team to do as part of its own refactoring that is part of the work in a sprint.

I like the idea of having tasks that are separate from user stories as the tasks aren't going to be something that you'd show to an end user of a system but could be something to help improve maintenance and the time it may take to develop some new feature. Depending on how many tasks, in terms of overall point totals as some tasks can be 2 minutes and others may be 2 weeks, have built up this may be what determines if the team takes a sprint and doesn't put in new features but works on tasks to clean things up which I have seen a few times where I work.

Improve this answer
1

In my humble opinion, yes you can use user stories for non-software development projects, not just process improvement tasks. Take for instance, 3 years ago I was the best man at my friend's wedding and I used the Agile methodology and user stories for planning the wedding. All the tasks we had to complete were written as user stories with persona, intent, justification, and success criteria for each user story. All parties involved took part in our daily scrum to discuss what we did the previous day and what we would be doing that day. Everyone was geographically dispersed hence we held conference calls for our daily scrum meetings, sprint planning, retrospectives, story writing and estimation sessions....you name it, we did it. We had 6 sprints in total (3 months) and the wedding was an astounding success with no stone left unturned. That is how flexible the agile methodology is.

Improve this answer
0

You have a profound issue when you put internal "user stories" into the mix with actual user stories.

Please reread as many definitions of "stakeholder" as you can find.

http://en.wikipedia.org/wiki/Scrum_(development)

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Read them very, very carefully so that you can see the difference between Chickens and Pigs.

Internal "user stories" are written by chickens.

Actual user stories are written by pigs.

Your "chicken-oriented" user stories are not very important. No matter how much management wants to track them as if they were real user stories with real value, they aren't real user stories and they don't create value the same way.

At the blurry edge of the argument is the QA issue. QA is important and without it, nothing works.

That doesn't magically make QA suddenly a pig. It makes them still a non-stakeholder. They provide support, infrastructure and an essential foundation for the rest of the work. But they're "user stories" are essentially different from the real user's real user stories.

If QA doesn't show testing an improvement in testing, no one goes out of business. Money is not lost.

If the user's can't conduct business in the first place, you're out of business. Money is lost. The entire operation is a total failure.

Don't commingle internal ("chicken") and real ("pig") stakeholders.

Improve this answer
0

The "chickens and pigs" comment misses the point. Internal stakeholders are chickens when it comes to the product being developed (unless it is being developed for them), but they are pigs when it comes to the development process.

The question you are asking is whether the sentence formula "As a , I would like to be able to _, so that I can __" would be useful for defining and improving business processes where the improvements do not require writing new software code. I came upon this thread because I am thinking about doing the same thing and am looking for best practice, but my strong intuition is that the answer to your question is "yes." The purpose of the sentence structure is really to force the writer to abstract away solutions that s/he might already have in mind and focus on what the user--in this case, the process user--wants to be able to do. I see no reason why the user story wouldn't be useful when applied to process.

The point about acceptance criteria is a good one, but need not be dogmatic about it (which is Agile anyway). It is a good exercise when designing any business process to ask, "How will I know if the change in process accomplished my goal?" It is true that you can't always run an automated test to answer that question, but that's not a reason to disqualify the user story as a tool.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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