Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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 '11 at 20:20

6 Answers 6

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.

share|improve this answer
    
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 '11 at 17:30

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.

share|improve this answer

Yes

any stakeholder, any feature that improves the system

[let the purist downvotes begin!]

share|improve this answer
    
+1 Just be clear on who the stakeholders are, i.e. devs, managers, etc. [Let the flamewars begin!] –  Michael K Jun 6 '11 at 16:50
    
I'm a purist, and i approve of this answer. –  Tom Anderson Jun 6 '11 at 16:57
    
I disagree but won't downvote because I appreciate your courage :) –  maple_shaft Jun 6 '11 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 '11 at 17:25

"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.

share|improve this answer
    
+1 Eloquently put. –  maple_shaft Jun 6 '11 at 17:07
    
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 '11 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 '11 at 22:09
    
Good point. I rephrased the question and provided more context. –  Dan C Jun 8 '11 at 4:23

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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