There are many reasons why task breakdown does not work for pure agile delivery. The estimation practice has to work in different ways in traditional (waterfall) and agile deliveries.
One of the main differences between traditional and Agile is that in traditional, you know the details of all your requirements up-front. Whereas in Agile, you only have the high-level requirements, and you elaborate as you move on.
Traditional method for estimation (WBS)
Requirements → Modules → Task breakdown → Effort estimation → Project cost
When you don’t know your requirement details up-front, how would you do a task-level breakdown? Apart from that, when your requirements can change and evolve (the agile way), how would you manage your WBS?
There are many disadvantages to using a traditional estimation method in an agile context. Some of them being:
– Task breakdown is a technical view of the work in hand
– Task breakdown is difficult to understand for the product owner
– They don’t know what they are paying for and how much value is realized for finished tasks. i.e the product owners do not realize the cost of each feature
– Tasks breakdown gets into thousands of line items and difficult to maintain
– Change in one task affects related tasks; change in requirement affects too many tasks
– Difficult to allocate, manage task interdependencies, and assign ownership
– Cannot measure productivity and improvements as you move along in a project
– Cannot measure scope change ; only able to tract effort change
– Cannot link effort change to scope change where increase in effort is caused due to increase or change in scope
In order to overcome these challenges, we use the ‘story point sizing’ technique.
Agile method for estimation ( Story point sizing)
Requirements → Stories or Features → Story Point Sizing → Effort estimation → Project cost
In agile, we avoid doing a task-breakdown to derive at the project cost. This method eliminates all the disadvantages stated above. We will discover how.
What is size?
While estimation is measuring the cost of the work, Sizing is nothing but ‘measuring the amount of work’ in producing the feature. The trick is to derive the size first, and then the effort. The effort needed by two different programmers to produce a feature may be different. (Due to factors like skill, experience, domain familiarity, etc..). Nevertheless, the size of the feature remains the same for both.
There are many methods to sizing like function point, story point etc. For agile projects, the features are in the form of stories, and story point is the best method for sizing.
What is Story Point?
Story Point is a unit of measuring ‘size’, same as ‘kilo’ or ‘pound’ is a measure of weight. Story point is nothing but the measure of complexity of a story or a feature. Take an example of a typical story: “The user wants to enter his user name and password, click the login button and login to the application”
In a traditional approach, If we were to break this down into tasks, we would end up with tasks like database creation, table creation, creation of the UI layers, writing test cases, testing, making fixes etc.
Developer A will say: I need 2 days to do this” while Developer B says “I need 5 days to do this”
These numbers are not a true measure of the complexity of the job. They are debatable and they indicate the ‘effort’ as perceived by developers of varied skill and experience levels. How would you really measure how complex or how big the story is? How would you compare it with the ‘size’ of another story?
Typically in a product backlog, we have many stories. What story point sizing is intended to do is to ‘weight’ each story and decide how big (complex) each one of them is. (Mind you, we are not talking about the effort involved in making the story). If we say a story A is 1 story point (1 SP), and story B is 3 SP, it just means that Story B is 3 times as complex as compared to story A
In short, the size indicates how complex a feature(story) is, how much is the amount of work (scope) required to make the feature, and how big the feature is.
An apple = A pear = 3SP means, you can replace feature apple with the feature pear and it should have no impact to the overall scope of the project and the overall cost of the project (provided there are no other dependencies that will generate more work)
Note that size is not effort. Example: A story/feature to build a login screen is sized as 5 SPs. Person A has estimated 2 days to do it, and Person B has estimated 5 days to do it. The size remains the same, but effort may vary.
How to measure the size?
There are many ways to measure size, one of the simplest (not necessarily the best) being T-Shirt sizing. We can go “Simple”, “medium”, “large” etc.. Most of the time, it is based on assumptions and hunch. Again, the question would be how many story points constitute ‘simple’, how many story points would mean ‘large’? I would call this the ‘lazy sizing’ method.
One of the best ways to measure size is to go by the Fibonacci series. The idea being, the complexity of a feature hardly increases in a linear fashion. Normally, the complexity tends to increase exponentially.
If the stories are very clear, we should be able to break them into a reasonable level of granularity. A size of 21 certainly implies hidden complexity or an extremely large feature. Very large features are not desirable in an agile team. Large features are risky and there is a possibility of discovering hidden complexities during the sprint and the team may not be able to complete them in a sprint.
The team should re-look at each of these very large features and see how they can break them down into smaller features of lesser size. Note that as the story gets larger, the confidence level of the estimate gets lower.
How do you derive at the Size?
You can use many techniques for sizing. One of the most effective ways to measure the size is by using a good ‘sizing framework’. There is no ‘one-size-fits-all’ framework that is off-the-shelf. Mature agile teams can easily build their own framework using the parameters applicable to them. It is possible to derive sizing frameworks that can work across technologies. We have been successful in building frameworks that could size features across projects of open source technologies, Microsoft technologies, as well as legacy technologies like COBOL. Framework building is a big topic in itself (that is for later J ) . But generally, the idea is, against each feature, you input the relevant parameters and the value against each, you can easily derive how many SPs are each feature.
Here you can see that eight stories are sized to be a total of 28 SPs.
Baselining the scope through sizing
The amazing thing here is that, by using sizing, you are able to measure and baseline your initial scope. This is very important for an agile team to baseline the scope as the requirement may change and there are not tight change management processes.
In traditional method, scope baseline is the WBS. This is our ‘agile’ version of the scope baseline. Further down, I will explain how to re-scope and re-baseline.
Deriving effort from the size
Now the question is: How do you convey to your business stakeholder about the ‘cost’ of the project? Its pretty obvious they would not want to understand or hear about story points. I have experiences where some of my very junior project managers got trashed by the clients for showing them the story point estimation.
Once you are able to measure the size, you can derive at the effort easily. There are three main methods to do this:
Situation 1: Historical information exists and team is stable
The team is not a new team and they have been doing sizing and project execution for a reasonable amount of time. In this case, the team has to look back at their last 3 sprints sprints (the most recent ones) and calculate how many SPs are delivered and how much effort is spent to deliver them.
Eg: If the team has delivered 100 SPS with an effort of 500 combined hours, 500/100 = 5 hours / SP.
In this case, they would take 28*5 = 140 hours to complete the 8 features.
If cost of an hour = $100, the 8 features would cost $14,000
Situation 2: No historical information, new team
In this case, the team can pick few features that are indicative of all the features. They can do a task-breakdown estimation of these features and extrapolate it to the whole lot.
A word of caution here that as similar to any sampling exercise, the features you pick need to be good enough that they are exhaustive of the scope of the project.
In this case, if stories 1,3,6,and 8 are similar, you can choose any one. For instance, story 1
Stories 2,4,7 are similar, so you pick story 2
Story 5 is unique, so you also pick story 5.
Do a task breakdown of stories 1,2 and 5 (combined size of 12 SP) and you find that the effort comes to 60 hours.
i.e. the effort for 1 SP = 60/12 = 5 hours.
There you go ! As in the previous case, you can compute the effort of the project as 140 hours and the cost as $14,000.
Situation 3: No historical information, new team, research type project
Here is the most difficult situation. In this case, what I suggest is to go ahead and do a task-breakdown of all features at least for the first few sprints. When you do it for few sprints, you will see that you are able to measure your velocity. It may go up and down first few times, but will definitely stabilize few sprints into the project. Once you build up historical information, you can switch your sizing technique to method (1) mentioned above.
Changes in the scope and re-sizing
During the course of the project, changes are normal (hey, we are Agile!). But how do we keep track of these changes and if we produce more than we originally planned for, how do we justify that?
Another main dilemma of a project team is how they justify the effort over-run caused due to changing requirements?
The fact is, a bug produced by the team will not change the size of the story. But, a change requested by the client may result in change in size. The idea is to keep track of the change in scope by re-sizing the story every time there is a change. This re-sizing is also exposed to the product owner to avoid disputes later.
Note that in this example, two stories have changed (in yellow) the scope and a new story has been added. The original scope baseline was 28SP and the revised scope is 34SP.
It does not require a genius to figure out that 6 additional SPS would take 6*5= 30 more hours to complete with an additional cost of 30*$100= $3000
The team has to have good discipline to be able to re-size every change. This is how change management is done in Agile.
Measuring the team’s productivity through sizing
Few sprints into the project, you will see that the velocity (number of hours / SP) of the team stabilizes and reaches a plateau. This would be your optimum productivity (or perhaps not!)
There is always room for improvement, and by looking at the hours spent/ SP, you can clearly see how your team’s productivity is improving. If there is any productivity dip in any of the sprints, you can retrospect and find out the reason as well. It could be due to a new team member, attrition, unexpected change, etc. Nevertheless, without implementing sizing, it is impossible to measure real productivity.
Just by observing the effort variation is not an indicator of productivity. If scope is changed and effort is more, productivity could still be good. If scope remains the same and effort is increasing, the productivity is declining.
Too long for a blog already. Maybe one day soon we will get into the intricacies of the sizing framework 🙂 Adios!
Just wanted to correct you WBS is not an estimation technique at all and there are other estimation techniques who you can probably compare with SMC, Forward FP. Also it would be good to cover how and when re calibration needs to be done
Gee thanks, Well wisher.
WBS based task breakdown and estimation is one of the oldest and popular methods being followed since ages. You can refer the wiki link : http://en.wikipedia.org/wiki/Software_development_effort_estimation
When it comes to sizing, yes FP is one of the posible methods.
Function points are great from an accuracy stand-point. But the challenge in agile projects is that you hardly ever have all your requirements to the minutest detail. Moreover, your deliverables are stories / epics and features. They would hardly make sense for a pure agile team to have to split their user stories into the FP (outputs, inquiries, inputs, internal files, and external interfaces) mould. An agile team has to estimate a deliver a whole story. The value is otherwise ‘zero’.
FP is are known to be accurate and gives your estimations a great deal of credibility. If you work on a big long project it might be useful to invest in a very official-looking detailed estimation sheet. But if the level of uncertainty is big to start with (solution integration, legacy system, ad-hoc requirements…) you will not get (or expect)upfront precision anyway. If it is the case a faster way of doing the estimates with a high ROI on time invested, user stories and story points are better.
I have done FPs by taking days, and spent few more days trying to explain to the stakeholders without much success. Unfortunately it was just too technical for them. I have seen service companies use this method too just for the same reason 😉
Mike Cohn in his book “Agile Estimating and Planning” consider FPs to be great but difficult to get right. He recommends the story points-based estimation (obviously) !
i love your blog, i have it in my rss reader and always like new things coming up from it.
Nice usage of visuals!
As much as I would like to recommend Size based estimation, it’s difficult to use in low trust environment when biz/IT needs lot more higher confidence in estimation while projects are funded. As you said size is not effort. For a team with no history, it makes it more difficult.
I personally think WBMD estimation rocks in such environments (which are more often than usual). thought?
As for your particular situation, I suggest to use relative T shirt sizing through poker estimation and to convert to man days. (by extrapolation)
Sizing will help you control the scope.
Man days will satisfy the business.
Moreover, if the project is large, I believe its going to be painful to have thousands of lines of task-breakdown items and expect to be accurate about it.
Personally, I have given up task break-down several years ago. I have nightmare expereinces with thousand line items managed through mpp 🙂
I wouldn’t suggest task based estimation either. What I suggest is story level estimation in effort range (5-9 days of effort – hence 5 points).
It one of the strangest things I have heard 🙂 if you already derived the effort (wonder how..), why bother with the points at all?
The whole idea of sizing is to make the estimation process easier and logical.
And a classic mistake: 1 md NOT= 1 SP
I’ll keep my position when it comes to dicede whether customers should care what methodology you use.Anyway you raise one interesting point uphill battle of small companies trying to deliver quality results focusing of software craftsmanship. I don’t say this is an easy battle but definitely not loosing one. If you happen to meet customer who is aware of different software development/project management methodologies and wants to know how the vendor works they will likely choose one of these small shops. Why? You already gave the answer: no bullshit (or significantly smaller chances to get some).
Congrats Nisha to come up with a simple yet detailed agile estimation method.Will you able to flash some light on, what are the ideal candidates for Story point sizing framework parameters.
We didn’t study estimation @ CUSAT right. 🙂
yes we never got to any estimation in CUSAT 🙂
I will try to share the parametres for the sizing framework soon. I have a framework that was working for scrum projects. I need to back-test it with an existing project running on XP practices to ensure the accuracy and then I am happy to share.
Nisha – great stuff. Would like to know your perspective on how Story Point technique can be standardized across different projects.
Here is a similar read on agile methodology and scrum methodology but still struggling with estimation in them.
Good learning from this article. Can you please provide some examples of what can be the Parameters (typically) for a feature or story where you provide values and finally arrive at the # SPs. Thanks.
One more clarification. Can you explain how you would arrive at 60 hrs in ‘Deriving effort from the size – situation 2’ .. any guidelines to arrive at effort when you breakdown to tasks. Stuck here.
I think 60 hours is assumed here as an effort given by team to complete the 3 stories with 12SP.
Can you please provide parameters for sizing framework you talked about in the article above ?
Situation 1: Historical information exists and team is stable:
How you have derived 28 in:
In this case, they would take 28*5 = 140 hours to complete the 8 features.
Ok, i got about 28:
28 SPs for 8 features as you have shown in example… no need to reply….
Thanks for very clear explanation on Story Points sizing and calculation of effort based on SPs.
Please keep posting more articles on Agile.
I read it again and realized that to complete 1SP team effort was calculated as 5 hrs., so to complete 3 strories with 12SP, the effort would be 12*5 = 60hrs.
Please ignore previous reply by me.