Skip to content

user stories

Story Dependencies

As I mentioned in this post, I am pretty annoyed with myself because of the way I structured stories in the first release of my current project. Here are a few things that I learnt. First of all when we say that Story A is dependent on Story B, it means that Story B development cannot start until Story A development is complete There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner. Types and Approaches Situation 1 – The wrong splitThis is the classic vertical split. Many… Read More »Story Dependencies

Can you shuffle your stories?

No? Neither can I and I am not happy about it. So I got my new iPod Touch. One thing I find slightly annoying is the fact that when you select an album it gives you the list of songs. But the first option is “Shuffle”. Being used to LPs and Cassettes and CDs I don’t really like to shuffle songs. I have listened to my favorite albums in a given order of songs for so long, that I want to listen to them in that order. So I started wondering about the requirement for a shuffle option itself. And… Read More »Can you shuffle your stories?

A Bunker Buster coming!!!

Get Down!!! Take Cover!!! A bunker buster on it’s way here guys……been a long time since I wrote one of those šŸ˜€ But then again, as Nassim Taleb says in The Black Swan What you know can’t hurt you (much) More on the book later. I still got to finish it.And by the way, have a wonderful New Year guys.

Choose your lanes

Starting a new project is always fun. For Agile/Lean teams setting up the story wall is a part of the fun. Some would say you are defining the process that you want to follow. The life-cycle of the user stories from being analyzed to delivered. But thereā€™s more to a wall than defining the story lifecycle. In its wall the team chooses what it wants to monitor. The lanes on the story wall are statuses in which the story can be. An agile team wants to track these statuses to quickly find problems that are slowing the team down. These… Read More »Choose your lanes

Can’t negotiate size… and a good thing too

In many companies the Business Analyst or the Project Manager ā€œestimateā€ the project and bind developers on the project to that estimate. This is an absolutely brutal thing to do to your project. But even within agile teams where the developers estimate, the Business Analysts or Project Managers sometimes tend to challenge and negotiate developer estimates. Not because they donā€™t trust the developers but merely out of selfishness. Because it gives a tremendous kick to deliver something that a client wants faster. Now if the team is ā€œestimatingā€ in a ā€œtime basedā€ unit such negotiations make some sense. Because a… Read More »Can’t negotiate size… and a good thing too

Size or Estimate

Estimation, I think, has been one of the biggest problems of mankind. The Software development industry is no exception to this sad reality. We almost never seem to get it right. The problem with the word “estimate” is that it’s personal. It’s relative to the person who is estimating. Moreover, it’s a unit of time. That is why I prefer “sizing” stories rather than estimating them. Size is a non disputed (standard) unit, which measures the level of complexity involved in developing a piece of functionality, a story. The size is standard across a particular project team. Pizzas are a… Read More »Size or Estimate

Mountains to climb

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

How to eat an elephant?

The only way to do that is to cut the elephant into slices. Slices which are small enough to be eaten because the sole purpose of cutting the elephant is to make it possible for humans to eat it. You’ll need a certain number of people to eat a whole elephant anyway. If you make slices small enough, at least they won’t feel sick at the end of it. There is no overhead in the activities of choosing the piece that looks most delicious, putting it in your mouth, chewing it and swallowing it. There is some, but it definitly… Read More »How to eat an elephant?

Embracing Bunker Busters

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

Avoiding 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