Requirements, Specs, and Managing Up in an Agile Environment [closed]

Question

My company has tried to adopt the scrum methodology with mixed success. Theses are some areas where we've had issues. How do you handle these?

1. Tracking requirements from Product Marketing through to product. We're trying out JIRA to track all requirements individually and assigning a release to each one as it is picked for implementation.
2. Who creates stories? Product Management who doesn't know enough to create effectively small stories, developers who may not have domain knowledge, an analyst in between?
3. Functional specs
   1. do you write them or just try to get them into a story definition?
   2. Do you write functional specs per story? Per feature?
   3. How do you see the relationship between functional specs and stories?
4. answering the question from people with VP in their title "what are we going to get by [8 months from now]?"

Answer 1

Let's see if my take adds anything (not certain by any means...)

1. I'm not sure about the "assigning a release to each one" thing. I thought the idea was to put a "price" on each story/function point/unit of development and pick what goes into the current sprint. Everything else is backlog - you can offer some indication of remaining effort (see evidence based scheduling in FogBugz) but I don't think you should be allocating to specific sprints - you don't know what'll be in the backlog by the time you get there, for one thing. All you know is that it's going to change, so why waste time on it?

2. There should be a designated user representative. Or more than one, if domain knowledge can't be concentrated in one individual. But someone from the business domain should be in charge overall of deciding what goes into a sprint, subject to the effort available, of course. There can be a place for a Business Analyst type, but they need to be domain experts. If your user(s) can't write stories, even with your help (it's a co-operative thing, or should be) then you all need help. Consider getting a coach involved for a sprint or two.

3. You won't be writing functional specs in an Agile environment. You'll be writing code. Your user will be on hand at all times (or you're already exposed to significant risk) and they're your spec. The story tells you "what", and is going to be a small enough unit of work that you should be able to decide on "how" fairly quickly. And refactor. Always refactor. It's not an overhead, it's part of the process and your design won't evolve satisfactorily without it.

4. If you have VPs (hey, I'm a VP, we're not all bad!) who ask that sort of question, then parts of your company are not getting it yet. Choose someone (the person best able to deal with non-techies, perhaps, or maybe the person least able, since they clearly need the practice) to explain it to them. If what's built is important to them, perhaps their questions are an indication that someone's not as involved as they should be.