Skip to content

user stories

Grenades, Shells & Bunker Busters

As agile business analysts, we try to keep our stories small, independent, testable and valueable. Once in a while, though, we come face to face with a Bunker Buster and everything starts looking scary. Impact Every story is likely to impact a certain portion of the developed application. Measuring this impact and using it to “time” a story well, is something commonly ignored by business analysts. This doesn’t mean that the analyst or the team doesn’t know the impact of a story but this measure is not used in planning exercises effectively. We can almost categorize stories to get a… Read More »Grenades, Shells & Bunker Busters

Deceptively small stories??

For sometime now I have got the feedback from developers, that the stories I write look small but have loads of work to be actually done and they get under estimated during the Iteration Planning Meeting. Now when I asked for a way in which I could make the story look as big as it is, I was given the idea of putting tasks in the story. I have used this method for sometime now and I find myself writing things like: TASK 1: When the user clicks “OK” an empty Word template should be uploaded to the server and… Read More »Deceptively small stories??

Value..

Stories being testable and valuable is as important as them being small and independent. Perhaps more… because these are the two important characteristics which in fact drive the size of the the story. Like we saw that an agile analyst can sometime fool himself by creating independent stories, one can also blunder quite easily when it comes to testability and value of stories. Let’s look at an easy example: Imagine a customer entity in a system with about 50 odd attributes. Creating one story capturing all these attributes will be a real mess. An analyst would (and should) readily want… Read More »Value..

Chicken and Egg

Managing dependencies is another tricky issue that plagues agile business analysts. Fortunately it’s not as bad as the chicken and egg problem. The secret to successfully solving dependency problems is to start at the beginning… Well maybe an example will help. Let’s consider a system that sells books online. The roles which will interact with this system, will be– the buyer– user registration– the administrator– the sales team and– the warehouse manager. The most important entity in this system in undoubtedly the book. Starting to write stories for creating a book is an obvious start for anyone. Now this is… Read More »Chicken and Egg

Small Stories, Large Stories

One question that keeps analysts busy for a most of the time is whether or not to split a story. Here’s my philosophy behind my unending support for small stories. Let’s start with one huge story that covers everything that is required to be done in a project. It is estimated by the developers at say 120 complexity points which converts to about 300 days. Following are the consequences. A requirements document (the story) – coupled with the time taken to prepare such a document The techinical discussions and decisions for implementing these and of course the time required The… Read More »Small Stories, Large Stories

Once upon a time…

User stories are the basis of business analysis in an agile project. A user story is an artifact which captures a small but valuable piece of business functionality which can be implemented and tested independently. The philosophy behind agile methodologies is basically iterative development with short & fast feedback cycle which is used in improving the solution and accomodating changes (subject to priority) so that the end result is really what the customer wants. Inevitably this creates a unique position of a business analyst as a broker between the customer and the developer. Writing user stories is what this broker… Read More »Once upon a time…