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 split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)
Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.
If your body is vertically split in half as in your left is separate from your right...
The first place to look for the vertical split is Admin Functionality / User side of the application. If you see your stories divided like Admin Stories and User Stories make as big a noise as you can quickly.
Situation 2 - The application flow
This is where we just plainly don't think.
Example:
When you get a message on Yammer, Yammer sends you an email. You can click on the email to look at the message you have got. BUT you can obviously keep your Yammer client open and see the message instantaneously and thats the way it's supposed to be used.
Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.
Such errors are much easier to spot. Beware of the Business Process Workflows that you refer to. The business process workflow DOES NOT represent development flow. Mark the niceties and essentials apart in your workflow.
Situation 3 - Data dependence
This is a little more tricky. But I have seen this a lot of times as well. This is closer to David's comment on my earlier post.
Surely to sell an item, you need to set the item up in the system. Doesn't this mean that you have to build the Item CRUD features into the system before you can sell it.
NO!!
Theoretically the items could be setup directly in the database. If the goal of the system is to sell an item, then that's what should be done first.
Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.
The first thing is to concentrate on the crux of the system. Selling Stuff, Lending Books, Renting out DVDs, Playing Music, these are the things to achieve as early as possible in respective projects. Therefore you need to do whatever is needed to get to these areas as soon as possible.
Musings-at-the-end
I was mostly plagued by the admin V/s user situation throughout this release. We split stories that way because there was a tough deadline to meet and we thought it's better to split the work so that more pairs can work on the project. It worked out alright and we are in the last iteration and even able to provide a few more story points than promised. But we did face a lot of problems in scheduling because we split the stories in a wrong way. So that's definitely something to avoid.
Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.
If you have a team of fairly experienced, "like minded" developers... can they agree upon a few conventions to follow so that two pairs can work on "Setting up the Item" (Admin part) and "Using the Item" (User part) simultaneously? I am still talking about evolutionary design (code as well as database). I seem to think that with good build processes, this should be possible.
What do you think?
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 split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)
Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.
If your body is vertically split in half as in your left is separate from your right...
The first place to look for the vertical split is Admin Functionality / User side of the application. If you see your stories divided like Admin Stories and User Stories make as big a noise as you can quickly.
Situation 2 - The application flow
This is where we just plainly don't think.
Example:
When you get a message on Yammer, Yammer sends you an email. You can click on the email to look at the message you have got. BUT you can obviously keep your Yammer client open and see the message instantaneously and thats the way it's supposed to be used.
Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.
Such errors are much easier to spot. Beware of the Business Process Workflows that you refer to. The business process workflow DOES NOT represent development flow. Mark the niceties and essentials apart in your workflow.
Situation 3 - Data dependence
This is a little more tricky. But I have seen this a lot of times as well. This is closer to David's comment on my earlier post.
Surely to sell an item, you need to set the item up in the system. Doesn't this mean that you have to build the Item CRUD features into the system before you can sell it.
NO!!
Theoretically the items could be setup directly in the database. If the goal of the system is to sell an item, then that's what should be done first.
Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.
The first thing is to concentrate on the crux of the system. Selling Stuff, Lending Books, Renting out DVDs, Playing Music, these are the things to achieve as early as possible in respective projects. Therefore you need to do whatever is needed to get to these areas as soon as possible.
Musings-at-the-end
I was mostly plagued by the admin V/s user situation throughout this release. We split stories that way because there was a tough deadline to meet and we thought it's better to split the work so that more pairs can work on the project. It worked out alright and we are in the last iteration and even able to provide a few more story points than promised. But we did face a lot of problems in scheduling because we split the stories in a wrong way. So that's definitely something to avoid.
Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.
If you have a team of fairly experienced, "like minded" developers... can they agree upon a few conventions to follow so that two pairs can work on "Setting up the Item" (Admin part) and "Using the Item" (User part) simultaneously? I am still talking about evolutionary design (code as well as database). I seem to think that with good build processes, this should be possible.
What do you think?
I'm not sure I see a difference in your vertical split stories and data dependence. Of course, working on both at once when the code is new will produce some headaches. But admin stories vs. user stories are just a question of data dependence and you can delay the admin side of a thing until the user story(s) is fairly stable. Given that, can you give a different example of a verticle spilt that caused a problem.
ReplyDeleteAdmin V/s User stories, I agree, are data dependence problem. And I think I used the wrong term to explain Situation 3.
ReplyDeleteThe problem is not that the crux of the system requires data. That's a fact. The problem is that we build elaborate functionality to create the data through the system before we tackle the main business functionality.
Let's take an example of a simple MP3 player software. The main business functionality is that of playing music. The only real data dependency is that the songs should be in proper format. But time and again we make the mistake of building elaborate functionality to edit and display ID tags before we play music.
So Data Dependence is a wrong term to describe Situation 3. I think we can call it the "Foundation Release" problem. Since it involves over engineering basic entities in wake of building a foundation for the project.
Akshay, that is a better example. Also, in terms of prioritising, generally speaking, a client would want to see the playing of music as proof of requirements being met rather than the 'admin' functionality. I like the idea of a 'Foundation Release' and it is akin to building just enough to meet the highest priority requirements.
ReplyDeleteI was actually talking of the "Foundation Release" as over-engineering WITHOUT providing the basic functionality.
ReplyDeleteBut you got my point that we should provide basic functionality first and then the bells and whistles.
Have you seen.... http://lizkeogh.com/2008/05/14/rip-as-a-i-want-so-that/ ?
ReplyDeleteI saw it now. It does make sense from planning a release point of view but my original problem in this post was about managing dependencies.
ReplyDeleteI am almost perpetually thinking about story value and using the "In order to" / "so that" parts of the story properly. I am wondering if there might be a way of structuring the "so that" parts so that they can be tracked in a I knew an old lady kind of way.
nice blog post!!!
ReplyDeletetop analytics companies
Analytics for Micro Markets
Business Analytics
business data analysis