There have been multiple traces of origins to this terminology so far the Agile programming goes. By and large the proponents are indebted to the ad makers who traditionally prepare the storyboard while creating an advertisement. The concept of storyboard was eventually borrowed by many streams of content development including those done for digital consumption. Before getting into the definition of Story in Agile Programming, let’s dig out the definition of storyboard first: Storyboards are organizers to depict a series of illustrations or images that would get composed sequentially to display the purpose with better visualization. (Multiple Internet based sources)
Now let’s look into the definition of Story: A story is a high level depiction of the user requirements, which would provide just enough information to the programmer to estimate and implement the requirements. (The Agile Modeling website)
While the similarities are quite obvious, I would like to highlight the words “high level” in the definition of the stories in Agile Programming. Depending upon how the user perceives and composes the requirements, the stories can be of diverse shape and size. However, the objective here is not to write a requirements bible, but to communicate the needs or expectation from the software application. So, the user story may well start with a bulleted list of actions to show how the business process should be. Subsequently, each of the bullet points would be blown out to a set of user screens, business rules, data units, etc. In other words stories are expected to branch out as the requirements evolve, and so is the development work.
Being discreet in providing high-level and just enough information to the programmers would ensure that more iterations happen during the course of development, thus enabling the test driven development more rigorously. Let me explain, how it works. For sake of simplicity, let’s assume that the story under consideration talks about developing one screen. The story provides just enough information so that the developer would be able to develop the UI with all the input/output controls positioned correctly. Immediately after that, the programmer would need to know the input validations to be implemented. The story-writer could have given this in the first cut of the story itself. But there would be some limitations: a) the story-writer might not have thought of all the validations that would be required; b) the programmer would have to wait till the story gets completed with the description of validations. So, the first story came out without any validations requirements. After implementing this, the programmer went back to the story-writer (or user group, or product owner, whoever are in the loop) to show his work as well as to gather some more requirements (validations). Now the story-writer could see how the UI came up, and could provide some upfront review comments on it. At the same time, the story-writer now would be able to provide more crystallized information on what kind of validations would be best fit here. With this second story, the programmer goes back to work and implements the review feedback and the new set of requirements (validations). Then comes the requirements related to the more comprehensive business rules, like how the input data should be saved, how it should be deleted, browsed, and so on. The beauty of this iterative process is it keeps the programmer and the story-writer (normally the user representative) continuously engaged with the happenings around the software development. So the risk of expectation mismatch with the users is minimized to the lowest probability.
However, it comes with a pinch of salt, too. It sets the pre-condition of having the user groups continuously engaged with the programmers. Those who work in the IT consulting space know very well what I am talking about. It’s not easy to get such a high degree of time commitments from the user groups since they too have their daily chores to take care of. To them, contributing time in larger chunks with lesser frequency would be a preferred option than what I have been writing in the paragraphs above. Such a situation creates the weakest link of failure in the Agile programming, as the lack of frequent iterations would eventually result of delayed completion of tasks.
To those who are consultants, and are doing programming for your clients (external organizations), my suggestion would be take a judgment call here. Not too high-level, not too detail-oriented may turn out to be a critical success factor for most of you, specifically those who are competing for your clients’ time as users and trying to make a killing using Agile. Nevertheless, as Agile is gaining popularity, you would also see quite a few organizations are committing larger share of the users’ time during the development of the software application.
We will talk more about such trade-off later in the following posts. Now, I would like to move on to the topic of Backlogs. For those who would like to develop deeper understanding on Stories, may go through one of the early attempts to compile the subject within a book: User Stories Applied - For Agile Software Development (by Mike Cohn)
No comments:
Post a Comment