Agile Montage

The mindset, when it comes to software development, implementation, and rollout has changed a lot in the last few years. The early years were all about planning, designing, replanning and redesigning, developing, implementing and rollout. This age is all about doing precisely the same things as above, but in much smaller and frequent intervals. That's the difference between Waterfall and Agile sofware development mindset. Agility, however, demands a change in the size of each individual problem that is to be solved. In other words, problem is broken down into smaller chunks of work that are then tackled in a fixed but small interval of time, called iterations. So, instead of tackling the huge problem, we now deal with features that are right sized for an iteration, which can be a week, two week, or three weeks long - called "stories". Stories Stories became the way to implement functionality in Agile environments. It still is and probably will continue to be the way for another few years until something new and better come across. This is because it is manageable, concise, and yet valuable. However, in a large problem space, the identification of stories still remains an art. There is no science behind story identification. And, as is true with any art, only a few are masters at it. For the rest, it's still a nightmare when someone asks, "Are there any stories missing?", or, "Have you been able to identify all the stories?", or worse yet, "Based on the stories that you have identified, how long do you think it'll take us to build a fully functional software to market?". Questions like these have forced the agile practioners (analysts) to reconsider the way they view the problem space. While they realize that stories are the way to build sofware, one piece at a time, it is probably not the right level of granularity to begin with. That ought to be the scenarios. Scenarios We should not jump straight into breaking the big problem into stories directly. There's an intermediate step, called the scenarios. What all would an ideal and super user of the software would want to do, in his/her typical day? The answer to that, usually, is a collection of scenarios. So, if the problem space is to build a end-to-end front-end equipment leasing system, a scenario in there could be: "User generates and prints lease documents". "User converts lease documents to different industry standard formats".

Benefits

Scenarios are proving out to be a necessity as the complexity and scope of the solution keeps growing to handle the 21st century global businesses. It ensures that the functionality needed in the solution doesn't remain hidden or unidentified. Stories can then be stem out of these scenarios. The other way round, stories can always be traced back to the scenarios. Overall, there's a better management of stories; missing ones can be identified and added soon, and the duplicates can be identified and eliminated as easily. There's yet another soft benefit to it. The teams can be divided to work on scenarios rather than disparate and unrelated pieces of functionality. For the product owners it becomes easier to see the big picture and priorotize functionality. Scenarios also make the release features easy to decide. So, as an example, with scenarios identified the product owners can decide that as part of release 1 the users would be able to generate and print but won't be able to convert documents into different formats like PDF, etc.