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've been studying couple of books of how to exactly implement agile. I am confused about release planning.

Our application is a Insurance System consisting of different modules (Quoting, Policy Management, Claims management etc). During the first phase we are just planning to release Quoting and we are estimating approximately 4 months for it.

Now my question is, do we have to identify user stories for overall system (including all the other modules) first before start working on our first release (i.e quoting)? Or is release planning is an iterative process too?

share|improve this question
1  
What in your books indicated you would need user stories for future features, modules, etc.? –  JeffO Sep 26 '11 at 20:03
    
Wel it just says that initially you need to explore the system. Find our Features/user stories and depending on the features that would give you more value, you should prioritize them. Now I'm confused that if my system has different modules, do we need to explore features for entire system during the initial phase? or should we just explore one module at a time? –  TK Lee Sep 26 '11 at 20:10
    
@TKLee: Please update the question to make it perfectly clear. Please don't add a long comment that's hard to read. It's your question. You can make it more clear. –  S.Lott Sep 26 '11 at 20:18
add comment

3 Answers 3

Agile == Iterative.

That's all there is to it. Everything is iterated. Requirements. Design. Code. Test. Development Sprints. Release Sprints.

Every day is an iterative process of daily stand-up followed by work.

The Whole Point is to avoid the cost and risk of attempting to foresee the future and magically plan everything. It cannot be planned, so don't try.

Do we need to explore features for entire system during the initial phase?

You can't. So don't try.

You can't foresee the future. After you start releasing parts your users learn -- and you learn -- and you realize that what you originally thought was wrong.

Agile == Learning. Learn as you go. Allow the project plan to reflect learning as you go.


During the first phase we are just planning to release Quoting

Why? Is this highest business value to the stakeholders? Is this the most important part? Does this create the most immediate, short-term, "right-now" value for the users?

share|improve this answer
    
"Agile == Iterative" doesn't always hold good. At times, there could be a clear visibility on the project. Again, its a matter of common-sense to choose whichever is required. –  Arvind Chinniah Sep 27 '11 at 4:17
    
@Arvind C: "there could be a clear visibility". If you think you have clear visibility, you have probably overlooked something. Don't trust your imagination of the future. Iterate always. You can't really see the future, no matter how clear you think it appears today. –  S.Lott Sep 27 '11 at 4:21
    
I would not use Agile == Iterative but Agile => Iterative because Spiral model or V-model are also "iterative" but I would not call them agile. –  Ladislav Mrnka Sep 27 '11 at 8:55
    
@Ladislav Mrnka: One can argue (from a historical perspective) that "Iterative => Agile", also. The spiral of v-model are older and merely preliminary steps down the road toward agility. –  S.Lott Sep 27 '11 at 10:02
add comment

The further away something is on the horizon, the less granular the planning should be.

For example:

  • Ensure you have acceptance criteria specified for all the stories the team might get to in the next 2 weeks of work (e.g. in the Given/When/Then form).
  • Ensure you have identified stories for the next 10 weeks of work. Just one sentence will do (e.g. using the As a ... I want .... So that form).
  • Ensure you have high-level epics/features listed in a roadplan covering next 6 months and beyond
share|improve this answer
add comment

Do not identify user stories for the overall system. The time and effort will be wasted because the Customer will ask for changes as soon as they see the first demo from you.

Instead, work with the customer to define user value Quoting stories for each iteration within the first release. Deliver user value stories as early in the release as practical so the customer can try out your work.

Say for example, that your product must provide quotes for both auto insurance and homeowners insurance. You might create one user value story for each and then first deliver the one the Customer says is most important. After seeing your work, they might decide that the Auto-Quote module is so good that they want you to deliver the Auto-Claims model next instead of homeowners. Hopefully you get the point that it's about delivering value to customers early to help them make informed decisions and help you improve the product efficiently.

share|improve this answer
add comment

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.