The point of doing User Stories is to make requirements more granular.
One of the core agile practices is writing requirements in the form of user stories. This approach to requirement gathering exists in pretty much any flavor of agile software development process.
Challenges with Estimating
In order to really understand the rationale behind creating user stories we first need to understand the process of estimating the duration and effort for software development work (or any work to that extent).
Every time someone is asked how long or how hard it would be to implement a certain feature or a set of features they are facing two-dimensional uncertainty. The first thing they need to figure out is what exactly they need to do (or how it should work) and the second how they will be doing it (the technology and inner mechanics of the project). The bigger the task the more difficult it would be to give an accurate estimate and the greater the chance we will miss something.
Here is an example: someone asked you to estimate how long it would take to build a new web site for insurance company where people will be able to purchase insurance policies on-line. How long do you think it will take you? And what is the level of confidence you have in your estimate? Would you feel comfortable committing to this timeline?
Now, imagine that you were asked to estimate how long it would take to build a new web page on which the user will be able to enter their personal information and home address, and that should result in the system creating a new profile for this user and redirecting the user to their profile home page. Would you be more comfortable estimating this or the entire web site? Would you be more confident in your estimate for this feature?
User Stories vs. Traditional Requirements
This is where the user stories come into play. Instead of defining a gigantic set of requirements that is likely to change half way through the project anyway the requirements are defined in a form of user centric stories:
As a new user I should be able to register new account by clicking on Register button on home page and then I should be taken to the New Account Registration page where I can enter my first name, last name, home address, and email. After successful registration I should be taken to the My Account page and the new account should be created.
Compare this to the more traditional form of capturing the requirements:
R1. System should allow for the new user registration
R2. Registration should start with clicking on Register button on the home page
R3. During the registration process the new customers should provide:
- 1. First name
- 2. Last name
- 3. Home address
- 4. Email address
R4. After registration the customers should be redirected to My Account page.
Which one is easier to visualize? How about estimating?
There is, however, another important aspect that often gets overlooked. More granular requirements are easier to track. Imagine that you have a 20 page long document that contains the complete set of requirements for your system. Some of them are implemented, some of them are still being worked one, and some of them have not even been looked at. How would you estimate your progress on this project?
If you had the requirements defined as user stories and each story would be estimated separately then it would simply become a matter of doing the math. You can easily calculate the total amount of work (either in hours or points) minus the completed work.
If you kept the user stories small enough and did an OK job estimating them then figuring out when you will be done becomes a fairly trivial process. You know how long it takes to complete one story (again either in hours or points), you should know your team capabilities. Put it together, and you will get the rate at which you can be completing your requirements.
For example: you have 30 user stories ranging from 8 to 24 hours of work each. For simplicity we will not talk about duration vs. effort at this time. All of them together come to 1000 hours of work. You have 6 developers on your team; therefore your total daily work capacity is 6 x 8 = 48 hours. Assuming that they only can stay focused on your project about 80% of the time while spending the rest of their time on some administrative work (time entry and other corporate stuff) you will have your team capacity at 38.4 hours a day. Divide your 1000 hours by 38.4 and you will arrive at 26 work days. This would be about 5 work weeks.
In this example 1000 hours would be called your back log and 38 hours a day would be called your projected burn down rate. You can even create a nice looking burn down chart.
Burn Down Chart halps you predict the actual project completion date.
In reality things can be a little different and more often than not the expected performance will differ from the real life productivity. After the first few days (weeks) you can establish your real burn down rate – the number of hours it really take to complete the projected (estimated) unit of work. After that you can recalculate your project plan and come up with more accurate reality-based dates.
Points vs. Hours
The approach above works well with abstract developer working in vacuum. In real life different developers have different productivity. This is the reality. To address this problem the user stories can be estimated in some relative units of complexity (points). It is not really important what one point would equate to as to make sure that all stories that estimated with two points have about the same amount of work and are about twice as more complicated as stories that have only been estimated with one point.
For example, let’s assume that one point is about 8 hours of work. In that case if we look at the example above we have our total backlog at 125 points (after combining all of the points assigned to all of the user stories).
We can again estimate our project burn down rate to approximately 4 points a day (38.4 divided by 8) or 20 points a week. This will give an estimated completion time of 6 weeks.
Is this accurate? It is just as accurate as estimating in hours. You never know how quickly you will be able to move until you start. After we finish first two couple of weeks we can correct the estimated burn down rate. Let’s say we found out that in the week one we only completed 16 points worth of work and week 2 we were able to finish 18 points. This would help us establish reality-based burn down rate. Let’s say we decided that we will use 18 point from now on (first week was really tough because it was a brand new project so we don’t want to use that data). Then our new project timeline is going to extend to 7 weeks.
Of course, it is not 100% accurate. A lot of things can still go wrong: you may discover a complicated problem, clients can change their mind, new legislature can be passed by Congress and impact your industry, etc. However, it is much more accurate that the traditional way of estimating the project based on traditionally defined requirements.