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.

I am writing a system where both the system owner and myself are developers, and we are currently the only source of 'requests' or requirements for the system, which I would like to capture in user stories tied to features{1}. My urgent priority now is to get a managaeble backlog captured. How should I go about capturing the level of technical spec I am used to to working with in users stories, which aren't supposed to be too technical.

{1} I am evaluating agile project management service TargetProcess, and each user story must be tied to a parent feature. The system seems a good fit, so this small constraint is something I would rather work with than work around.

share|improve this question

2 Answers 2

The typical story template is very easy to visualize:

As a [ROLE] I need to [WHAT] so that/because [WHY].

The interesting thing is that the importance of the components are reversed.

WHY is more more important than WHAT and that is more important than ROLE

Example using this Question

As a Software Developer I need to learn how to write User Stories so that I can populate the backlog with drafts to get discussions of the features started and get points assigned to them.

Anything more is over complicating the intent and the implementation of User Stories.

Additional Tools ( Integration is best )

Tools can be used to capture additional detail information about the stories that is captured when discussing them to assign points/estimation, but that detail should not be part of the story itself. Something as simple as a Wiki with 1 Page per story to put details/transcripts of discussions on is a good enough solution. Excel spreadsheet is a terrible solution.

share|improve this answer
3  
+1 for Excel spreadsheet is a terrible solution. –  ProfK Jul 17 '12 at 22:03

Focus on the what's and why's and avoid the how's when writing the user stories.

What you're faced with is actually a very good exercise for all developers. Being able to express the requirement in simple, business terms is an important skill.

You should focus on the general requirement such as "need to be able to make a single selection from a drop-down listing of objects so the user can enable Foo action" instead of specifying using a combobox or listbox or whatever that triggers a specific routine.

Another way of approaching this is pretending like the underlying code base / framework is almost complete black box. Any time you find yourself saying "use object XYZ", you can self-check by asking if you would know of that in a black box system.

Update:
IMO, it's okay to put details into a use case that indicate the level of detail required for information. For example, with an enrollment system it's fair game to specify
- last name; required field
- first name; required field
- account ID; system generated no input necessary
- astrological sign; optional field - (suggestion) provide lookup from entering birthdate?
- etc....

The key is that you are not specifying the technical how for that information. If you find yourself saying "use a String class / character array / or varchar field" for last name, then you know you are over-specifying.

If you're multi-lingual, then use two disparate languages as your litmus test. For example, strings in C are generally char(acter) arrays whereas C++, Java, and C# (okay, and almost everyone else...) have an actual String like object. If you find that your specification is invalidated by using one of those languages then you'll know you've over-specified.

It's worth noting that I'm specifically using the term Use Case as opposed to User Story, although the variant I end up using is a hybrid of both. My goal of a use case is to give an overview of what's going on (a User Story in the strictest sense) but then work through the actors, systems, and general functionality that's required. My approach is closer to what Fowler is suggesting in that wikipedia article as opposed to Cockburn's approach.

So I'll have a single use case (or so) for the enrollment scenario or work item. If it's really complex, I would break it out into multiples, but that's not a big deal. The use case can then be broken down into individual tasks as necessary. What's tossed into a particular scrum depends upon lots of variables, but there's nothing within this approach that prevents you from having a demonstrable component at the end of the scrum.

share|improve this answer
3  
Even saying “drop-down listing” might be over-specifying. –  Donal Fellows Jul 17 '12 at 7:53
    
@DonalFellows - That's a good point, and I pondered that one for a bit. I went with it since a drop down is a pretty standard, generic UI element that you'll see with wireframes. Listbox and Combobox are specific language constructs for drop down lists. +1 on the comment. –  GlenH7 Jul 17 '12 at 11:50
    
@GlenH7 I understand this, but my problem is I don't know where to capture the technical stuff. If certain fields are required for a e.g. new employee, I don't want to use a story for each field, but rather "as a user I need to capture field x and y", and "may choose to capture field q and z" type thing. If my quick examples here are the right direction, I will try more exercise that way. –  ProfK Jul 17 '12 at 22:08
    
@ProfK As an HR administrator I need to enter information about new employees so that I can enroll them in the payroll, 401K and insurance benefits systems. This should be a good Story, the details about everything else is just that details that should be documented in a wiki page or some other document. If the case of other new features need to be added to this story, new Stories with those specific requirements that were missed would become new stories in the system .The Story is done when this activity can be completed by the ROLE to the customers approval. –  Jarrod Roberson Jul 17 '12 at 22:54
2  
@ProfK - updated my answer in response to your question. IMO, I think you're on the right track. I've worked a lot of different methodologies, and the critical aspect to remember is to make it work for your situation. It sounds like you need a little bit more than what a formal User Story provides. So adapt how you generate your User Stories and keep moving forward. Some will probably flame me for the comment, but honestly, the whole point is to get code written and keep the project moving forward. –  GlenH7 Jul 18 '12 at 3:38

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.