Business Analysts work closely with the customer. Each new area is a challenge. There are discussions and problems and solutions. Both the analyst and the customer get comfortable with the idea of finding better, simpler solutions. This is especially true for fixed bid projects, as the project is at stake if the analyst fails to find a simpler solution and convince the customer too. Solving problems is always exciting. For an analyst, this is the juicy part of the job, because no human being can survive for long just writing word documents one after the other. One incentive is customer… Read More »Mountains to climb
For various reasons, there are situations when there is no running away from a Bunker Buster. An agile team should therefore be watchful. Once the analyst finds a potential bunker buster, he/she will have only one parameter to tweak… The timing. Embracing a bunker buster is a a brave step, I would say. But then isn’t, bravery only relative to the preparation?? SymptomsHere are some tips out of my experience for identifying bunker busters. Note that these symptoms do not decide a bunker buster individually. Like gesture-clusters in body language, they work in combinations. VaguenessThe first and most probable characteristic… Read More »Embracing Bunker Busters
“Prevention is better than cure” and one good way of handling Bunker Busters is to avoid them. Agile teams seem to be wary of handling anything by prevention, as it requires thinking ahead and taking care of things to come rather than things that are. While this makes perfect sense for Grenades and Shells, Bunker Busters have much more potential for damage and it is worthwhile trying to prevent them rather than handling them when they come. There are areas in every application which can prove to be huge bunker busters if not handled in advance. Teams are even aware… Read More »Avoiding 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
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??
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