Skip to content

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??

Communication Patterns

Incidentally my earlier post was about how Distributed Agile works. My unexpectedly long web silence was infact due to the current DA project that I am working on. One interesting thing that we get to observe is how the communication patterns change over time, amongst the local team and also with the distributed team. There are few specific things that I have observed during the last 5 months on this project, which I would like to bring up here. All of these relate to the communication that happens across oceans. OverviewLast few months I have been busy on a Distributed… Read More »Communication Patterns

Overseas…

So what happens to the agility when the project is distributed? Well, it suffers… It’s not that it doesn’t work in a distributed context. In fact ThoughtWorks has been doing distributed agile for quite sometime now. We talked about some of the best practices of agile earlier. Let us see what problems distributed agile poses to these principles. Time differenceWhen working across oceans, the first thing that hits the team is the time difference. The typical arrangement renders the team to be in a low cost country like India and the client in the US of A or Europe. The… Read More »Overseas…

Agility…

The key practices of agile software development, known and followed are:1. Face-to-face communication over documentation2. Quick feedback from end users over project phases (as in waterfall) Collective ownership, Pair Programming, use of whiteboard, paper, and most importantly the terrific visual representation of the project health and progress… the wall For an agile team the wall is everything. The action of moving stories & bugs along the columns and the instant snapshot of the project health is fantastic. Here’s how it works… The process : The Business Analyst analyzes the requirement and writes a story and acceptance criteria The developers estimate… Read More »Agility…

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…