Agile Estimating and Planning

Mike Cohn

Mentioned 19

Goes beyond the strategy of just enough planning and estimating, and shows readers how to make agile practices truly work organizationally.

More on

Mentioned in questions and answers.

My firm just got its first large-scale development project inquiry and I would like to use an Agile process. The client has a vision for the application but openly admits to having very few requirements and recognizes that we will have to charge by the hour. Because of this, I've all but sold him on an Agile approach.

The problem is that he wants a figure to budget around. I've read a number of articles that pretty much advocate against giving up an estimate because the client will budget for that number and even as requirements change, the number in their head and in the books doesn't.

I've read there are a number of ways to factor in pricing in the contract, but almost all of them (save one) incorporate an up-front number. This just seems to violate the entire set of principles of Agile development.

So my question is, if you're an Agile shop, how do you manage to circumvent this Catch-22 of Agile development?

This is a really tough issue. See what Robert Glass has to say on the subject in his book "Facts and Fallacies of Software Engineering". (Note that Amazon has books available new for less than they're available second-hand! [as of 2009-01-05 12:20 -08:00]; also at Google books.)

These answers are really great. I don't have a lot of experience to share, but I thought of an analogy:

Last year my wife and I remodeled our kitchen. The contractor proposed billing on time & materials instead of giving an estimate, because we didn't know what we'd discover with respect to plumbing, subfloor damage, and so on. We agreed, because I'm working from home and I was available continuously to answer questions. The contractor and I had a good rapport so when something came up, he felt free to knock on my office door and we'd discuss it. Decisions got made quickly and the work was done the way I wanted it. That seems similar to the Agile priority on frequent customer review.

By contrast, my wife's cousin is also remodeling his house. He's an ER doctor and he is not available on site during the remodel. So he described being regularly surprised by the contractors making major decisions without consulting him ("What? I didn't want that picture window blocked off! Tear out the wall and reframe the window the way it was!"). This is of course painfully expensive and blows the schedule out of the water. Definitely not Agile.

So one way to convince a client that a time & materials mode will work may be to assure them you'll make frequent progress reports to get their feedback. I believe this is already a core recommendation of most Agile methodologies. To begin, of course this requires the customer give their trust to the consultant.

As a separate resource, I searched and found a book on this subject: "Agile Estimating and Planning" by Mike Cohn. Read the praise quotes on that page, from an impressive set of Agile experts.

As the title suggest... How can I apply a scrum process to anything that doesn't work on new code and can be estimated to some degree?

How can I apply a scrum process to maintenance and emergency fixes (which can take from 5 minutes to 2 weeks to fix) type of environment when I still would like to plan to do things?

Basically, how do I overcome unplanned tasks and tasks that are very difficult to estimate with the scrum process? or am I simply applying the wrong process for this enviroment?

As the title suggest... How can I apply a scrum process to anything that doesn't work on new code and can be estimated to some degree?

On the contrary, I've heard teams find adopting Scrum easier in the maintenance phase.. because the changes are smaller (no grand design changes) and hence easier to estimate. Any new change request is added to the product backlog, estimated by devs and then prioritized by the product owner.

How can I apply a scrum process to maintenance and emergency fixes (which can take from 5 minutes to 2 weeks to fix) type of environment when I still would like to plan to do things?

If you're hinting at fire-fighting type of activity, keep a portion of the iteration work quota for such activities.. Based on historical trends/activity, you should be able to say e.g. we have a velocity of 10 story points per iteration (4 person-team 5day-iteration). Each of us spend about a day a week responding to emergencies. So we should only pick 8 points worth of backlog items for the next iteration to be realistic. If we don't have emergency issues, we'll pick up the next top item from the prioritized backlog.
CoryFoy mentions a more dynamic/real-time approach with kanban post-its in his response.

Basically, how do I overcome unplanned tasks and tasks that are very difficult to estimate with the scrum process? or am I simply applying the wrong process for this enviroment?

AFAIR Scrum doesn't mandate an estimation technique.. Use one that the team is most comfortable with.. man days / story points / etc. The only way to get better at estimation is practice and experience I believe. The more the same set of people sit together to estimate new tasks, the better their estimates get. In a maintenance kind of environment, I would assume that it's easier to estimate because the system is more or less well known to the group. If not, schedule/use spikes to get more clarity.

I sense that you're attempting to eat an elephant here.. I'd suggest the following bites

When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.

In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:

• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.

• The delivery date is set, and so we have to assign the appropriate resources to meet that date.

Kelly Waters has an interesting take on estimating agile here: Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.

It seems to me that we need to be able to do one of two things:

• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.

• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.

The first option is of course not an option in most cases. Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?

Alternatively, does anyone see another option for solving our problem through some other process change?

I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.

So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.

  • Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.

  • Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.

Again, for more details on how to do this read the referenced book.

Some questions about Function Points:

1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)

2) And is the effort required worth the benefit you get out of it?

3) Which type of Function Points do you use?

4) Do you use any tools for doing this?

Edit: I am interested in hearing from people who use them or have used them. I've read up on estimation practices, including pros/cons of various techniques, but I'm interested in the value in practice.

Mike Cohn in his Agile Estimating and Planning consider FPs to be great but difficult to get right. He (obviously) recommends to use story points-based estimation instead. I tend to agree with this as with each new project I see the benefits of Agile approach more and more.

1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)

As far as estimation precision goes the functional points are very good. In my experience they are great but expensive in terms of effort involved if you want do it properly. Not that many projects could afford an elaboration phase to get the FP-based estimates right.

2) And is the effort required worth the benefit you get out of it?

FPs are great because they are officially recognised by ISO which gives your estimations a great deal of credibility. If you work on a big project for a big client it might be useful to invest in official-looking detailed estimations. But if the level of uncertainty is big to start with (like other vendors integration, legacy system, loose requirements etc.) you will not get anywhere near precision anyway so usually you have to just accept this and re-iterate the estimations later. If it is the case a cheaper way of doing the estimates (user stories and story points) are better.

3) Which type of Function Points do you use?

If I understand this part of your question correctly we used to do estimations based on the Feature Points but gradually moved away from these an almost all projects expect for the ones with heavy emphasis on the internal functionality.

4) Do you use any tools for doing this?

Excel is great with all the formulas you could use. Using Google Spreadsheets instead of Excel helps if you want to do that collaboratively.

There is also a great tool built-in to the Sparx Enterprise Architect which allows you to do the estimates based on the Use Cases which could be used for FP estimations as well.

So you've just been put on the spot by The Boss. You've got 15 minutes to come up with a back of the envelope estimate for the addition of some new feature. Your boss (fortunately) recognizes that you can't provide an accurate estimate in that time so expecting something that is in the right order of magnitude.

The question is how do you go about giving a estimate in the time frame that is accurate to an order of magnitude?

Note that this is meant to be a quick and dirty estimate, not something that might be expected from questions like this

I've recently been reading Agile Estimating and Planning, and can't recommend it enough.

If you really need very quick estimation, you can do work breakdown structure with every task for 1-2 days or smaller and after this estimate every task by providing min and max estimated values.

sum of min and max values specify interval for the whole task. This gives information abouts risks to your boss, which is always very useful.

You will obtain some interval, e.g. 12-15 day or 5-30 days - this is much more useful than 16 day instead of mentioned intervals.

It can be useful for you good book by Steve McConnel Software Estimation: Demystifying the Black Art.

In an answer to the question Documents for a project?, Chris Ballance replied that "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.

My question is, do you know of any good example[s], which I can see (for example on the internet, or in a book), of these kinds of documentation?

If possible I'd be happy to see many examples, including:

  • Small/short/simple examples
  • Big/long/complicated examples
  • Famous examples
  • High-quality examples

I don't find this an easy topic to Google for: I find lots written about it, but fewer demonstrations showing it.

A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.

As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories

Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.

Hope that helps!

We are just starting on a pretty big project with lots of sub projects. we don't currently use any kind of named process but I am hoping to get some kind of agile/scrumlike process in by the back door.

The area I will be focusing on most is having a good backlog for the whole project and, at least in my head, the idea of an iteration where some things are taken from the backlog, looked at in more detail and developed to a reasonable deadline.

I wonder what techniques people use to break projects down into things to go in the backlog, and once the backlog is created how it is maintained and ordered. also how relationships between elements are maintained (ie this must be done before it is possible to do that, or this was one story now it is five)

I am not sure what I expect the answer for this question to look like. I think what may be most helpful is if there is an open source project that keeps its backlog online in some way so I can see how others do it.

Something else that would get +1 from me is examples of real user stories from real projects (the "a user can log on" story does not help me picture things in my project.


Like DanielHonig we also use RallyDev (on a small scale) and it sounds like it could be a useful system for you to at least investigate.

Also, a great book on the user story method of development is User Stories Applied by Mike Cohn. I'd certainly recommend reading it if you haven't already. It should answer a lot of your questions.

I would counsel you to think carefully before adopting a tool, especially since it sounds like your process is likely to be fluid at first as you find your feet. My feeling is that a tool may be more likely to constrain you than enable you at this stage, and you will find it no substitute for a good card-wall in physical space. I would suggest you instead concentrate your efforts on the task at hand, and grab a tool when you feel like you really need one. By that stage you'll more likely have a clear idea of your requirements.

I have run several agile projects now and we have never needed a more complex tool than a spreadsheet, and that on a project with a budget of over a million pounds. Mostly we find that a whiteboard and index cards (one per user story) is more than sufficient.

When identifying your stories, make sure you always express them in terms that make sense to your users - some (perhaps only small) piece of surfaced functionality. Never allow yourself to slip into writing stories about technical details that you could not demonstrate to a user.

The skill when scheduling the stories is to try to prioritise the things you know least about first (plan for what you want to learn, rather than what you want to do) whilst also starting with the stories that will allow you to develop the core features of your application, using subsequent stories to wrap functionality (and technical complexity) around them.

If you're confident that you can leave some piece of the puzzle till later, don't sweat on getting into the details of that - just write a single story card that represents the big conversation you'll need to have later, and get on with the more important stuff. If you need to have a feel for the size of what's to come, look at a wideband delphi estimation technique called planning poker.

The Mike Cohn books, particularly Agile Estimating and Planning will help you a lot at this stage, and give you some useful techniques to work with.

Good luck!

Technical Debt via Martin Fowler, via Steve McConnell

YAGNI (You Ain't Gonna Need It) via Wikipedia

BDUF (Big Design Up Front) via Wikipedia

UPDATE: To clarify the question, I think I can also state it this way and keep my meaning:

"In what ways do you, as an Agile practioner, find the right balance between "quick and dirty" (unintentionally risking Technical Debt while attempting to adhere to YAGNI) and over-engineering (BDUF) within each iteration?"

It seems that if you stick with the "plan, do, adapt; plan, do, adapt" idea of agile (iterations, iteration reviews) you would avoid those things by default. BDUF is just so contrary to the idea of agile estimating & planning that if you are really agile, you wont be BDUF automatically.

The purpose of release & iteration planning meetings is to make sure you are adding the most valuable features to the project for that iteration. If you keep that in mind, you'll avoid YAGNI for free.

I would very strongly recommend the Mike Cohn books on agile planning:

  1. User Stories Applied
  2. Agile Estimating and Planning

Update: After your clarification about avoiding YAGNI and BDUF within an iteration...

BDUF...If I felt a feature was not clearly defined before I started work on it, I would create a small "feature" or story to account for the design type portion of the work needed. So that maybe the smaller story has a story point estimate of 1 instead of the real feature's 5. That way, the design is time-boxed into the smaller story, and you will be driven to move on to the feature itself.

To avoid violating YAGNI I would work to be very clear about what the customer expects for a feature within an iteration. Only do work that maps to what the customer expects. If you think something extra should be added, create a new feature for it, and add it to the backlog of work to be done. You would then persuade the customer to see the benefit of it; just as the customer would push for a feature being done at a certain point in time.

I really like the concept in the agile manifesto that the focus should be on working software rather then on comprehensive documentation. On the other hand a part of my job is also to manage the product and as such I need a up to date version design document at all times. Some might say that the current version of the working software IS all the documentation that I need, but I need the documentation to prove that the product works as per the customers specifications, even after 10 changes to the original design.

In a previous job each and every approved change was integrated in a design document per major feature in the system. This procedure added a significant overhead to each change, since at least one and posible two word docs had to be updated, approved and signed.

At least this procedure worked in a waterfall project but now I am looking for a more agile way to document the current agreed state of the solution so I am really looking forward to hear how you handle this issue, thanks.

Edited: My issue here is how to track how come the system looks or behaves the way it does. So I have an existing system in production and the customers logs an issue that the system should do Y when X is entered. Then I'll need to figure out the current specification for that piece of functionality which might have been changed a number of times in various user stories, sigh.

A design document is essential, but a "complete description of all aspects of a system" type document, created at the beginning of a project, is not a good idea.

You will have to get away from ideas of a design for all aspects of a system that is carved in stone. You do start out with a design and then start breaking that down into user stories which are small concentrated tasks for the parts you will be working on immediately for the first sprint.

Aspects of the design that are being implemented later don't have to be as detailed and in the intial phases may actually consist of many user stories clumped together into a user theme. Even further out, you may have clumps of user themes grouped together into user epics. As the team progresses to later sprints, the user themes are broken down into individual user stories and the user epics may start to be broken down into user themes.

Each sprint may be considered a mini-waterfall project on its own so there will be a requirements gathering and design phase at the beginning of the sprint. This is where the design document is incrementally updated with th e new portions of the design.

This concept is covered in Mike Cohn's "Getting Agile with Scrum" presentation. I'd also recommend his books "User Stories Applied" and "Agile Estimating and Planning". If there are many of you new to Scrum I'd suggest getting Mike in to teach one of his courses to you.

Have a read of Martin Fowler's excellent essay "The Almighty Thud" about creating unnecessary documentation.

When estimating tasks, how does one break from the grip of Hofstadter's law?

While "Hofstadter's Law" is a bit tongue-in-cheek, there are a couple of practices that can help you, in particular for first-pass/large item estimation:

  • Estimate in relative sizes. Meaning you don't say that an item takes X time, you say that an item A is twice as big as item B, and that item B is about 4 time as large as item C.

  • Gather data from previous estimating rounds and use it as a base line. So that when you are estimating a project, and notice that item A is about as big as item B from a previous iteration/project, and you know that item B has taken 2 days, you know that item A will most likely take about as long

  • Use "wisdom-of-the-crowds" to get higher quality estimates. I've used Planning Poker in a couple of projects and the outcomes are rather good.

If you want to know more about this you can start by watch Mike Cohn's presentation (Part 1 and Part 2) and/or read his book. While it's not the end-all,be-all of estimation, he does present some good practices and best of all, the reasoning behind the practices.

How do you estimate the time needed to implement a user story? If it's something you had done before you know how long it'll take. But what about if it's completely new to you? How much time do you reserve for "surprises"?

A great technique for this is to break the story down to somewhat smaller tasks, and estimate them compared to each other (instead of absolutely). So you can say:

  • Task A will take 2 units (arbitrary)
  • Task B is about 2 times as complicated as Task A (4 units)
  • Task C is about half has complicated (1 unit)

We're better at estimating relative complexity than absolute complexity. Then you actually perform one of the tasks, and figure out how much "real time" it takes you to implement 1 unit - now you can calculate all the tasks. You keep updating your estimates according to how you progress.

This technique is from Agile Estimating and Planning by Mike Cohn, which is a great book on the subject.

We are currently utilising an agile environment in work. One of my tasks involve setting up a release timetable. A part of this is providing a time frame of how long a project would take to go from a development environment, to staging and then live.

I have conflicting thoughts regarding whether such a timetable needs to be done.

For a start, we are quickly moving into a Continuous Integration / Constant Delivery environment where an application is tested amongst all environments when a change is made to the code base. Therefore, there is no time frame, but things should be "just" deployable. (Well, we always need a little bit of contingency as the best laid plans can always go awry)

Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.



If you currently utilising and agile environment you should check Agile estimating and Planning book for some suggestions. This book also contains small chapter about Release planning.

Some release planning should be always done. Release is a target wich usually covers 3-12 months of development = set of iterations. It something which describes target criteria for project to success. It is usually described as combination of expected features and some date. Features in this case are usually not directly user stories but epics or whole themes because you don't know all user stories several months ahead. Personally, I think release is something that says when the project based on vision can be delivered. It takes high level expectations and constraints from the vision and converts them to some estimation. You can also divide project to several releases.

But remember that three forces works in agile as well. There is direct relation among Feature set, Release date and Resources (+ sometimes also mentioned fourth force: Quality). Pushing one of these forces always move others. It is usually modelled as equilateral triangle (or square).

There are different approaches to plan a release. One is mentioned in the book. It is based on user stories estimation, iteration length selection and velocity estimation but I'm little bit sceptic to this approach because you don't have simple user stories for whole release and estimating epics and themes is inaccurate. On the other hand high level feature definition is exactly what you need for three forces. If you don't have enough time you will implement only basic features from all themes. If you have more time you will implement more advanced features. This is task for product owner to correctly set business priority when dividing epics and themes into small user stories.

The most important part in agile is that you will know more quite soon. After each iteration you will have better knowledge of your velocity and you will also reestimate some planned user stories. For this reason I think the real estimate (accurate) and realease date should be planned after few iterations. As I was told on one training effort should not be estimated, effort should be measured. If anybody complains about it show him Waterfall and ask him when will he get relatively accurate estimate? Hint: Hardly before end of analysis wich should be say after 30% of the project.

It is also important what type of projects do you want to implement using agile / scrum and how long will project be. Some projects are strictly budget or date driven others can be more feature driven. This can affect your release planning. For short projects you usually have small user stories and you can provide much more accurate estimate at the beginning.

I usually maintain a release plan for the management that is mainly based on a combination of the estimated & prioritized user stories (I group them to match a main new feature of the product) and velocity.

With a well maintained product backlog it's pretty easy to do your release plan. I usually plan three to four releases a year.

What I like with Scrum is that I can potentially release after each iterations.

If you want to master your release management, you will need more information that few answers of practionners. I highly suggest you this book.

Am wondering, when a new project arrives, say building a social networking website, how do I go about breaking the project into small tasks. There are usually 2-4 programmers per project and usually no testers as such. Should I be breaking the whole site into 4 hour tasks from the beginning itself. Should we be doing it in phases? What about testing, is it okay to have the programmers test the code?

Thank you for your time.

That's a big question for a forum so I'll start with recommending a book:

Agile Estimating Planning by Mike Cohn

As you can tell from the title it is presenting an agile approach.

Until you have bought and read the book, this extremely short version might be of some use:

  • Do a coarse grain planning first. Something like: We'll plan to deploy the first version after two months, containing the very basic features to make it really usable. After that we will have a new version about every month. Make sure you don't get into to much detail. Since reality will kill all the detailed plans anyway. You can think of the steps in this plan as phases, but note that they don't match the classical phases analysis, design, implementation, test, deployment

  • For the first phase plan in more detail what you are going to do. Use vertical slices for planning, i.e. Do not plan: First we'll make the GUI then the model, then the database, but use complete features, often modeled as User Stories. e.g. "As a user I want to enter orders into the system" This would be one user story. The implementation of that user story would imply doing all the stuff from Userinterface to persistence, also including testing. (Google 'user stories' and 'iteration planning' for more information about this.)

For your testing question: Developers testing their code is better then no test at all. But there are better ways to ensure high quality of code. I'd recommend the following approach:

  • Do test driven development, i.e. write tests first, then the implementation. This kind of forces you and your team to make the code well structured, it supports rapid change of the code, since the tests will inform you about stuff getting broken.

  • Do pair programming at least part of the time (the more the better). This makes sure at least two persons understand each line of code. It also is works as implicit training and finally works as a code review, which is a good thing, since code reviews are known to be more effective in finding bugs than tests.

  • You will still need manual tests of the complete application.

More stuff to read and google: agile, scrum, xp, TDD, BDD, Planning Poker,

  1. Developing software solutions which already exist and are available for re-use (either commercial or open-source). AKA "re-inventing the wheel".
  2. Same as above, but your solution being broken. AKA "re-inventing the square wheel".
  3. Developing solutions for problems which do not exist.

Again, I'm interested in a more formal approach, e.g. TRIZ

Doing some research beforehand (1) and investing in solid software architecture (2,3) usually helps :)

When you're planning to develop something you always need to calculate the benefits of doing some and the things like the ROI.

You could read more about this in Agile Estimating and Planning by Mike Cohn

How do convert effort estimate say in function points to a specific web framework like django? Or is effort estimation solely dependent on the architecture of the web framework? ANy hints or guidelines would help.

EDIT would you be restrictive in thinking say, this is my framework, say django, and let me think in terms of converting my requirements into models and template.

or can i be generic in saying , these are my requirements, now these are my function points (any generic estimation technique) and can i convert this to constrains of django framework and come with effort estimate.

I like the Scrum concept of velocity when going from size estimates to schedule estimates and have applied it successfully for years.

The problems, user stories or features are estimated using some size unit: lines of code, function points, story points, ideal work hours, gummibears, whatever. Let's say we are estimating the size in "points".

To go from this size estimate to a schedule estimate, you apply the velocity: how many points worth of completed functionality the team produced in a given time, say a n-week sprint (iteration) where n is e.g. in the range 1..4. So if you have a velocity of say 300 points per 2-week sprint and you have 500 points worth of user stories to implement in your backlog. Therefore you need two 2-week sprints to complete them all. But usually it is applied the other way around: given a fixed duration sprint, which stories can be implemented bringing the maximum value and which stories should be postponed.

How do you get a velocity number? At first you have to guesstimate it. But right after the first sprint you will have some historical velocity data for your team. Start basing your velocity estimates on this data instead of guessing. The less you tweak the numbers, the more accurate they will be over time.

This way problem sizing does not have to consider anything else than the problem itself. Team characteristics such as experience, jelling etc. manifest themselves in velocity.

A good refence on the topic is Mike Cohn's Agile Estimating and Planning.

I am wondering, how "real" work day (7-8 hours) relates to "engineer hours" term used in estimation of the time necessary for completion of some task. I think that estimated effort in EH (if correctly estimated) cannot be simply translated into work days by dividing with 8, and that effective work day of a programmer is shorter than the time he spends in the building in which he works. This can lead to big errors in estimates when estimating small chunks of tasks (i.e. what is scope of one iteration in SCRUM) and when there are no best/worst case estimates, but planning is done based on individual task estimates done by programmers. When programmers need to estimate time necessary to do some individual tasks, they usually estimate the time from the moment they start working on it to the moment they complete it. Needless to say, it is insane to expect that someone will do 4 tasks of 2 hours each in one day.

I would like to know what are best practices in successful companies for relating effective time vs. time spent "at work" and are there some books or researches which estimate what is average time programmer spend working (focused on the tasks at hand), not doing other activities which are not included into estimate, like reading/writing mails (except ones included in estimate, if it is support task or similar), brainstorming, meeting, drinking coffee, estimating tasks and updating status in bug/task tracking tool.

If there are no books or researches, any links to articles about this issue by respected members of community will be of help also as I couldn't find any, these keywords are too generic.

Besides the mythical man month, which is always worth reading, Agile estimating and planning is one of the best books I found on the topic.

Best quote ever:

“There's no sense in being precise when you don't even know what you're talking about.” (John von Neumann)

Also, experimental software engineering attempts to draw statistically relevant conclusions out of experiments in a controlled environment. Very roughly you get to design experiments applying the scientific method, choosing input variables (ie. experience of the programmers, time of the week, language/framework, etc.), and measuring the output.

From wikipedia:

The scientific method suggests a cycle of observations, laws, and theories to advance science. Experimental software engineering applies this method to software.

A good book I remember from a remarkable university class on the topic is “Experimental Software Engineering”. It assumes you have a grasp over statistical distributions and descriptive statistics, but it's a very nice read.

There are two things that we do when we program:

  • Things which we've done that are similar to what's gone before, and
  • new things that we've never done before.

When we're repeating similar things, estimating - whether in points of relative effort / complexity or in hours - is usually fairly straightforward. Even when estimating in points, these can easily be correlated back to hours after a sprint or two, once the team has got up to speed.

The problem most teams face is that they're often doing new stuff. This is because:

  • doing a project where it's all been done before is pointless (see "Waltzing with Bears")
  • if it's all been done before, there's probably Open Source or off-the-shelf products which will do it for you, so learning how to use those may be new
  • developers hate doing the same thing over and over again, and would rather learn something new by automating it or producing a reusable library.

Thus, a lot of what we do on software projects tends to be new. The usual same-old same-old frequently ends up being given to junior developers, for whom it's new.

The trouble with new things is that you have no idea how long they're going to take. You've never done them before!

I've seen a number of strategies for handling this, depending on how determined someone is to (force devs to) produce reliable estimates, how much trust you have with stakeholders, etc.

  1. Pad the estimates horribly and then make the work fit them (this is what developers end up doing if PMs / SMs force them to produce reliable estimates, whether the devs realise it or not).

  2. Kanban's "classes of service" allow you to mix some new things with some familiar things. This will tend to allow a less variable flow through the development pipeline, so you can base your estimates on that.

  3. Do everything that's risky first (particularly if you don't know how risky it is!). Gradually the flow will stabilise. On a 9 month project, it took 3 months to start producing any kind of useful estimates, so careful with this one. The upside is that your stakeholders will see you addressing the things which keep them awake at night early, so trust can be high. Your PM / SM will go spare during this time. It's OK.

  4. Accept that the old metaphor of "time spent = work done" is a myth in projects involving high amounts of learning and knowledge work. It might have been appropriate in the days when developers were treated like a factory - churning out the implementation of others' designs - but in the world of Agile and Scrum, it's completely inappropriate. Even have recently removed the necessity for estimation and velocity measurements from their guide. Find other ways to develop trust, manage risk, win budgets and have conversations around the work - since these are the only reasons you need estimates in the first place.

I am a .NET developer wanting to build an SaaS based ecommerce system with B2B and CMS features (custom built, ASP.NET MVC preferably or using Dotnetnuke that enables SaaS scenarios). Technologies would be mainly Microsoft's (.NET 3.5, 4.0, Ajax, jQuery, Asp.NET MVC or MVP, SQL Server/MySql, EF 2.0, NHibernate, WCF, WPF, Window mobile 6.5, TDD/DDD).

I have a developer/architect asking me to produce a product backlog with ecommerce business requirements. I need to educate myself in how to do it intelligently and rapidly and I would use methodology outlined in this course: Agile Requirements Modeling - Personas, User Stories and Use Cases (I cannot attend it and I need to educate myself on how to best follow these practices).

Can somebody recommend any resources (books, videos, open source code, user manuals, real-world samples of product log) that will help me understand modern ecommerce business, interaction design patterns (since I want to have some GUI functionality built it and that will become some of product log items) and using Agile Scrum methodology? The best resource that would help me would be some real world ecommerce Product Backlog and Sprint iterations with possibly prototypes and interaction diagrams.

I know I ask a lot, but I am detailing my wish.

Thanks, Rad

I would recommend Agile Estimating and Planning for an overview of how to organise the project. For a dot net focussed book I'd recommend Applying Domain-Driven Design. There are many other excellent books that could be useful, but I'd begin with those.

Additionally keep an eye on InfoQ for a constant barrage of excellent material and talks. For example, here's a recent one on project metrics.

I am new to agile and have a query .We have sprint for one week with user stories.For a user story developers,UI and tester will estimate individually their time for each task

As you probably read, user story can be estimated in either ideal days or story points. Both have their benefits. Ideal days are easier to understand for a new team, story points are serving the scrum purpose better.

Very good literature about agile estimation is written by Mike Cohn you can find there more information about ideal days vs user stories.

In any case, the team should estimate size of the user story as a team, not individually. I know that it is very tempting and team members would argue that, how the developer can estimate testing? Scrum Master has to emphasize that they are a team and they are responsible for the user story as a team. They need to listen to each other and collaborate and agree on estimate.

Once a user story is estimated by the team the team estimates its tasks. This is usually done in ideal hours. This estimation can be done by individuals, but you need to take into the consideration that according to the scrum theory you never know who will take the task, it does not have to be always the person who performs the task the best.

If your team is new in agile this will most likely take couple of sprint so that team understands and gets used to the new way of work.