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 where the situation gets tricky. If all your initial stories are going to be related to books, they are inevitably going to be dependent on each other. For example :
View book details depends on Listing books which depends on Create book
Writing such stories doesn't make sense from a tactical perspective when we are doing iterative development because we can't develop such stories in parallel.
Instead if we decide to write a Create Book and a Register User story, we are suddenly in business. What this means is that we can start separate areas in the application simultaneously.
Sometimes however things are not as simple as that. There are various restrictions which can lead an analyst to write stories in the same area. What will typically happen is the analyst will write Create Book, List Book and View Book Details stories and get them played with valid assumptions and dummy data. The analyst has thus created independent stories... The consequence is the cost of integrating these pieces together.
There are several points in the application where everything comes together to form a complete picture. Integration of separate stories into a logical area and separate areas into a seamless solution is inevitable. What we need to understand is that reducing these integration points is optimal in terms of overheads.
Thus an analyst needs to take a call in consultation with the developers about finding v/s creating independent stories. Finding them is however definitly advisable.
If I were write user stories for evolution I think I would have developed the Chicken and the Egg seperately and integrated them in the end. Probably that's how it was done anyways!!!
Friday, March 31, 2006
Monday, March 27, 2006
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.
Agile works towards shortening each of these phases and doing them over and over again until all the requirements are fulfilled. Thus everything boils down to the feedback cycle you are looking at. Let's look at a shorter feedback cycle, say 100 days. Thus you end up with 3 stories with an estimate of 40 complexity points converting to 100 days. Which means you get feedback thrice during the project because the customer reviews the functionality delivered by each 100 day story as soon as it is completed. That's somewhat better.
Let's just try and make this a 10 day feedback cycle. We thus have 30 storys with an estimate of 4 complexity points converting to 10 days. What we are looking at is basically a 2 week iteration. Now that's really good. I'd however go for one more split so my stories have a complexity point estimate of not more than 2.
The upside
The upside other than what we established above is that developer estimates are generally exponential (although they are supposed to be linear). Which means that one 4-point is not equal to four 1-point stories. It is exponentially bigger. Thus the smaller stories you have the lesser will be the actual time taken to implement, test, get feedback, make necessary changes and deliver.
The downside
Well, there is no downside. The only thing required is constant interaction with the customer for analysis of new stories and review of completed stories.
Todo
An agile team should set customer expectations appropriately before starting the project. The customer participation is the heart of the project. Successfully establishing a short, reponsive feedback loop is the first and foremost thing to do when doing an agile project... and the stories, keep them short.
Small is beautiful...
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 implementation of this story
- The testing and
- The user acceptance (well usually non-acceptance and it takes very less time too :p )
Agile works towards shortening each of these phases and doing them over and over again until all the requirements are fulfilled. Thus everything boils down to the feedback cycle you are looking at. Let's look at a shorter feedback cycle, say 100 days. Thus you end up with 3 stories with an estimate of 40 complexity points converting to 100 days. Which means you get feedback thrice during the project because the customer reviews the functionality delivered by each 100 day story as soon as it is completed. That's somewhat better.
Let's just try and make this a 10 day feedback cycle. We thus have 30 storys with an estimate of 4 complexity points converting to 10 days. What we are looking at is basically a 2 week iteration. Now that's really good. I'd however go for one more split so my stories have a complexity point estimate of not more than 2.
The upside
The upside other than what we established above is that developer estimates are generally exponential (although they are supposed to be linear). Which means that one 4-point is not equal to four 1-point stories. It is exponentially bigger. Thus the smaller stories you have the lesser will be the actual time taken to implement, test, get feedback, make necessary changes and deliver.
The downside
Well, there is no downside. The only thing required is constant interaction with the customer for analysis of new stories and review of completed stories.
Todo
An agile team should set customer expectations appropriately before starting the project. The customer participation is the heart of the project. Successfully establishing a short, reponsive feedback loop is the first and foremost thing to do when doing an agile project... and the stories, keep them short.
Small is beautiful...
Friday, March 24, 2006
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 spends most of his time doing.
There are numerous ways of writing user stories but the goal is to capture a "role", an "action" and an immediate "goal".
Like:
As a Business Analyst
I would like to write my stories in "As a, I'd like to, so that" format
So that I can capture the role, action and goal easily
Ok, that's not an awfully great example... but the general idea goes thus.
User stories should be
This leads us to look at the meaning, purpose & priority of each of the above.
Valuable
The user story should deliver a valuable piece of business functionality. This is important so that the story can be released and used by the real users as soon as it is developed, thus giving the team a faster feedback.
Independent
Independence is a very important characteristic of a user story. When a story is independent, it can be picked up for development anytime during the iteration. It can deliver a valueable business functionality independent of the rest of the feature.
Testable
A story needs to be testable. Which means that the desired functionality that a story aims to deliver should be capable of being demonstrated, for all related business scenarios.
Small
A user story should be as small as possible... possible keeping all the above characteristics in mind. You can choose to split a functionality into shorter stories as long as it remains Valuable, Testable and Independant.
This is the primary job of the broker and what's challenging about it is what I'll be posting hereafter alongwith my version of the solution.
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 spends most of his time doing.
There are numerous ways of writing user stories but the goal is to capture a "role", an "action" and an immediate "goal".
Like:
As a Business Analyst
I would like to write my stories in "As a, I'd like to, so that" format
So that I can capture the role, action and goal easily
Ok, that's not an awfully great example... but the general idea goes thus.
User stories should be
- Small
- Independent
- Testable and most of all
- Valuable to business
This leads us to look at the meaning, purpose & priority of each of the above.
Valuable
The user story should deliver a valuable piece of business functionality. This is important so that the story can be released and used by the real users as soon as it is developed, thus giving the team a faster feedback.
Independent
Independence is a very important characteristic of a user story. When a story is independent, it can be picked up for development anytime during the iteration. It can deliver a valueable business functionality independent of the rest of the feature.
Testable
A story needs to be testable. Which means that the desired functionality that a story aims to deliver should be capable of being demonstrated, for all related business scenarios.
Small
A user story should be as small as possible... possible keeping all the above characteristics in mind. You can choose to split a functionality into shorter stories as long as it remains Valuable, Testable and Independant.
This is the primary job of the broker and what's challenging about it is what I'll be posting hereafter alongwith my version of the solution.
Subscribe to:
Posts (Atom)