Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We have a team of about four developers working in Scrum with two week sprints. We use YouTrack and when performing time estimation in Sprint Planning, we hit the two weeks of work quickly.
The issue is, for example, developer John will pick the first item on the backlog and say it'll take about 1 day. Developer Brian will take the next item and say it'll be about 1 day. Of course, that's actually only one day's work if each developer works on each piece, but YouTrack will sum it as 2 days.
When the whole team doesn't have to work on the same item at once, how do we appropriately estimate time? Are we breaking Scrum rules somewhere?
If we're doing it right, and we have to just go over two weeks, how do we be sure we're not giving ourselves too much work?
It should NOT be only Complexity but include Complexity, Effort, Risk and a gentle touch of common sense.
I think you are estimating in the wrong way to begin with, which has nothing to do with Scrum, Kanban or XP. You are estimating in a per person basis which should be actually done on per Story basis. Think about the feature as a whole and then estimate the story and not individual member's effort towards it.
Estimating by man days/hours have always been criticised as it doesn't involves the skill set measurement. Say, one feature with complexity 5 can be done in 1 day by a senior engineer but it will take 2 days for a new joiner or less experienced member. Hence, you can't take only complexity into account to measure the story sizes and sprint commitments.
Many people estimate Stories using complexity only and then sub-tasks according to hours, that has drawbacks as well due to duplication of effort in the actual estimation. Above all, always keep in mind that an Estimate will always be an estimate and Planning poker can only help you find it but it is not the ultimate estimation technique.
Adding my five cents here, complexity of the backlog items is not judged by individual team members.
First of all, a backlog item most likely involves more than a single team member and could be broken down to smaller tasks like 'implement UI', 'run tests' or 'change the database schema'. So there will be both John, Brian and maybe also Mary (a testing engineer) involved. And thus you'll need to estimate 'Complexity, Effort, Risk and a gentle touch of common sense' for the whole team, not just for John or Brian.
Also John, being a senior guy, might say it is of complexity 2, while Brian (a junior) could say it is 5 and Mary will notice a lot of regression because of the database schema change and give it 8. In the end in Scrum it comes to the whole team's commitment for the sprint. So you, as a Scrum Master, will need to facilitate John, Brian and Mary to come to an agreement and here's where tools like planning poker come to the stage.
As far as I know and understand, you don't estimate effort in Scrum. You estimate complexity of user stories in relation to each other and the contained functionality.
Following this, you estimate story points, not man days. The burndown chart shows your team's progress. Over time you get quite an accurate team velocity which basically tells you how many story points your team gets done with per sprint.
Use this team velocity as a basis to decide whether to commit to another user story for any given sprint, or if it will probably be too much.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I was going through the definition of Velocity of a project. As per my understanding its the number of story points acheived vs planned in an iteraction.
I am not clear on what is a story point?
Story Point is an "arbitrary" unit of work assigned to a particular task or story.
It can be the number of man-hours the team (or the team leader) estimated the task/story would take, but it could be just any other unit of work/time.
The specific unit used for a Story Point is somewhat arbitrary in a sense that it doesn't even need to translate into a precise amount of man hours (or of work days or what not). The only requirement is that the Story Points reflect the estimated amount of a work each task or story will require in a consistent fashion.
If the story point are assigned in such a consistent fashion, story points become a useful metric for measuring progress on the overall project. Also, if the amount of work programmers can perform during a given span of time (say during a 2 weeks "sprint") is expressed in story points, it is possible to plan the list of stories that can be delivered during the sprint (if all goes well ;-) )
A story point is something used by the scrum to estimate work effort on a story. It's an arbitrary measure such as person-hours, or a simple {easy-peasy, one-for-the-graduate, medium, guru, crikey-thats-a-toughie, near-impossibility} ({1, 3, 9, 27, 81} sort of thing) selection.
Hence a fairly simple story (hello, world) might be one story point, while a more complex one (a Facebook clone) would be many more.
Really good teams will maintain a history of stories and their points (both estimated and actual).
That way, you can just go find an earlier story similar to the one you're estimating and use its actual point count (found once the story had finished) as a baseline for the current story.
See this entry in the Agile FAQ for more detail, or the top page for lots of other goodies.
It is the complexity of story that is used to measure the team velocity. Normally, it is not precised hours the story will need because you can't know specially when you are a new agile team. But with time you will be able to more precisely assign a number to story because you learn with time.
Since main purpose of point is to get an estimation to measure your speed therefore you keep in mind the complexity of story (e.g, implementation time + team skills + knowledge + experience in the domain ,etc )
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have been using agile approaches (XP and Scrum) for my projects for several years with great results. But in all cases, all members of the dev team were committed 100% to the project.
Now I am faced with doing this when the team is not stable. For instance, one iteration there may be four people working, the next maybe only two or three.
I realize this makes it hard (or impossible) to estimate using the normal velocity approach since it will fluctuate to much and not be stable. What follows is that one cannot really expect to be able to release at the end of each iteration.
Maybe another approach is needed here. Just grab stuff from the backlog and just muddle through and release whenever it is possible. I really don't like that though...
Any thoughts?
From the question I assume you have some developers (probably, 2) 100% commited to the project and some (another 2-3) only participate at a times.
One thing you can do is set different process for core developers who are 100% commited and everyone else. Use you normal agile process for core people and release their work at normal iteration cycle. For non-core people, do little planning and assume their (and your) estimates would be way of at a times. Ideally their changes should be isolated and merged into stable branch of code by core members, but not every project's architecture and team roles allow this.
The point is to separate and isolate source of chaos and leave the heart of a project and team unaffected.
Maybe instead of agile approaches, you can slow things down with other iterative and incremental approaches. Instead of having iterations measured in weeks, having longer iterations (perhaps measured in months) would be better if you keep adding and dropping people from the team.
This doesn't mean that you still can't use some Agile techniques. I would still maintain your Backlogs and burn down charts, with the realization that instead of having a release every 2 weeks, you'll release every 6 weeks (~2 months). If you have new developers joining more experienced developers, use pair programming, assign the new developers to bug fixes, or assign the new developers to maintaining unit tests to help them learn the code base.
Velocity is only an estimation.
Naively, if you have a given velocity v with a team of 4 developers, then schedule your iteration with a velocity of (v/4)*number_of_developers
You can fudge this value if the members you are losing are particularly stronger or weaker than the average.
This is basically what PivotalTracker does with its team strength metric.
So, you have a project with a continually changing team size and your boss wants you to give him an accurate estimate of how long it will take? You can do this, as long as you keep in mind the difference between accurate and precise. Your precision will depend largely on the number of items and how granular (decomposed) each item is; the more items you have the more the Law of Large Numbers works for you, averaging out over- and underestimates.
Your accuracy is a function of confidence. Note that estimates aren't single-point values, they're a range with numbers with a percentage of confidence. For instance, a proper estimate wouldn't be "2 weeks" it would be "50% confidence of 2 weeks, 80% confidence of 4 weeks."
If I were the person assigned with the unenviable task of providing an estimate to completion for a project being managed as arbitrarily as in the original post, I'd try to figure out a range based upon the minimum number of folks assigned (e.g., "48 to 66 weeks given 2 developers [50% to 80% confident]"), and a range associated with the average number of folks assigned (e.g., "25 to 45 weeks with 5 developers [50% to 80% confident]"), and use the low figure from the average number along with the high figure from the minimum number (e.g., "25 to 66 weeks given anywhere from 2 to 5 developers [50% to 80% confident]"), and even then I'd put a disclaimer on it ("plus 10% for the lost time due to context switching").
Better yet, I'd explain exactly why this arrangement was, to be polite, sub-optimal, and why multi-tasking is a primary signpost on the road to project Hell.
As someone else suggested, changing the workflow from iteration-based to flow-based (Kanban) might well be a good strategy. With Kanban you handle changing project priorities by changing the priority of items in the backlog; once an item has been grabbed by the team it is generally finished (flows all of the way through the workflow, stakeholders aren't allowed to disrupt the team by screwing around with work-in-progress). I've used Kanban for sustained engineering projects and it worked very well. Re how it would help with estimates, the key to continuous flow is to try to have each work item be roughly the same size (1x, 2x, 3x, not 10x, 20x, 100x). You should track movement of items through the workflow by tracking dates of process state changes, e.g., Queue 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrate 2/7, etc., and then generating a cumulative flow diagram regularly to evaluate the time-in-state durations over time. Working out how long the project should take given that you know the size of each item and the time through the workflow for items is a trivial computational exercise left to the reader. (The more interesting question is how to spot constraints... and then how to remove them. Hint: look for long times in states, because work piles up in front of constraints.)
Let the individual developer that will be working on the story estimate the effort required to complete the story. You can take into account historical variances in that developer's estimations, but the idea is that you can take their estimates and then figure out how many stories you'll be able to finish in that sprint.
Don't forget that average velocity is largely used for lookahead release planning; the team is responsible for selecting in each iteration how many backlog items to take on (although knowing historical velocity can assist them).
If your team size (and hence velocity) is fluctuating from iteration to iteration, you can still do useful release planning by using average velocities over the past N sprints, assuming the team fluctuations will continue and hence their long-term average velocity will actually be stable.
Your main problem here is that the team will find it hard to give predictable estimates and deliveries since the team is changing from sprint to sprint. This can also hurt the team commitment and continuous improvement.
This case might actually be well suited for a Kanban approach. Check out Henrik Knibergs introduction to Kanban for a quick overview.
Good luck!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Note : Before asking this question I did an exhaustive search, and found little bits of the answer in various other questions, for example:
What is the best resource for
learning Scrum?
Scrum Process
Management - tips, pitfalls,
ideas
Two questions regarding Scrum
However, I feel like this question hasn't been directly addressed (if it has, please let me know).
Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not? Can you adjust those tasks and estimates?
Background: Our new VP of development came from a Scrum environment, and so we're all learning about the process, but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.
But it was my understanding that agile practices, specifically Scrum, were based upon the concept of tasks being buckets that store individual deliverable goals, and you add/remove/adjust them as the clients' needs evolve after each sprint.
I realize this could potentially be argumentative, but I assume that viewing Scrum as a process, only one of those concepts is the "correct" philosophy for that system.
Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not?
I track the estimated remaining work. This is a must have information. Without this, you can't draw the Burndown Chart. Without the Burndown Chart, you don't know "where" you are, you don't know if your Sprint is still on track or not. This would make this decision tool pretty useless. Yes, the Burndown Chart is not a tracking tool, it's a decision tool.
Can you adjust those tasks and estimates?
Sure!
Actually, the team owns the estimates, nobody else, and it is the job of the ScrumMaster to guaranty that this principle is applied. This should already answer the question. But there are other reasons.
As I said, a Sprint Backlog and a Burndown chart are decision tools and should thus be representative of where you really are. If you hide the reality, if you are not transparent, these tools won't help you to take any valuable decision, they will be useless. Think about it, what's the point of having good looking numbers if they are useless? What's the point of having a "nice looking burndown" if it doesn't reflect the reality.
So, during a Sprint, team members should obviously update the estimations of the remaining work as soon as they can do it (upward or downward). If a task estimate was initially 6h but the team discovers that more work has to be done and that the task will actually take 8h, the team should update the Sprint Backlog accordingly. If someone spent 4h hours on a task that was initially estimated at 4h but still need 2h work, these 2h should be reported on the Sprint Backlog. If the team discovers a task that has to be done but that wasn't identified, the team must add this task and its estimate to the Sprint Backlog. And being not accurate in the start is not a problem, as long as you update the backlog with the knowledge gathered over time. The sooner you make these updates, the sooner you'll be able to adapt and take decisions.
That said, it can be useful to keep the "initial estimate" and to compare it to the "actual time spent to complete". But not for tracking purpose, only to help the team to make better estimates. Actually, I would advice to not do this if you are transitioning to Scrum. There are often many other impediments to solve, many other things to improve first when you are learning Scrum values and principles. And if you do it, beware of the Waterfall daemons. Be ready to fight them, they may come back very fast.
The answers I see here aren't wrong, but I don't think they've really addressed your question.
I think you're asking, "Should I track the total hours actually spent on a certain task?" The answer is, "You can if you need to, but it isn't part of Scrum."
Scrum is a very lightweight process. It defines/requires only what is needed to make Scrum work. You can (and, in many cases, probably should) overlay other processes on top of Scrum in order to suit your organizational needs. For example, if tracking the total hours actually spent on a task enables you to better estimate similar tasks in the future (as it seems your VP wants), then that might be a good reason to track total hours, provided that it doesn't interfere with productive work too much. Or, perhaps you need to know the total hours for billing purposes. So just because Scrum doesn't require something doesn't mean you shouldn't do it.
However, for the purposes of Scrum itself, there is no need to track the total hours actually spent on a task. It is not needed for any of the Scrum artifacts, which only track the estimated amount of time remaining.
I don't know if our implementation is "correct", but what we do is:
Have Backlog Items added, which we put an estimated complexity number on (in relation to other backlog items).
Before each sprint, we go through the backlog items in priority order (prioritized by the product owner), break them down into tasks for which we make a time estimate (in hours).
When the number of available hours in the sprint are used up, the sprint is full
Then, during the sprint after each day of work we adjust the times on the tasks that we have been working on, so that they show the number of hours that we think is left before the task is done. This means that if I have a 6 hour task, work on it for a full day (we consider 6 hours a full day) and then feel that I still have 2 hours left before it's done, then I take down the "hours left" from 6 to 2. In case the task is time-boxed we need to check actual hours used instead, of course.
I have to add something here because
but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.
Is just plain not scrum so I don't know where your VP got his info. Tasks (know as Sprint Backlog Items) are not created until Planning the next sprint. They are created just in time and certainly not before the project starts. Before the project starts (Sprint 0), the Product Owner creates the Product Backlog and fills it with stories. He can add to it at ANY time during the project. It is his to manage. The team estimates these stories roughly against one another in story points or some other relative measure (ideal days?).
The estimating of tasks in hours is only a tool the team uses to figure out how many stories to commit to in the sprint and then to plot progress to predict success (burndown). Once a team has gelled and has a historical velocity; it may decide to not do any tracking in hours at all and just track their burndown in story points or # of stories. Estimating in hours is a form of waste in itself if the team does not need it to achieve commitment to the sprint goals.
I would ask the VP what these "very careful" estimates are going to accomplish.
Estimate time, but don't really care if it's spot on
Just make sure you are careful and estimate tasks thoroughly. Basically you don't really measure time, because it's more error prone. The best way is to use tasks' time estimates as story points. This way you will gain:
If your time estimates are off, research shows that they tend to be consistently off (accuracy factor doesn't change too much), so time estimates can easily be used for story points calculation.
If you empirically managed to do x number of story points in previous sprint, you'll probably achieve similar results this time round even though your time estimates are incorrect.
You will have to be rather good at estimating all story tasks. Otherwise your sprint story points tend to grow during execution and you won't meet your deadline - even though your velocity will remain practically the same
Estimates can change but similar to #3, keep some sprint slack time for these changes to meet sprint deadlines (demo day).
But keep time estimates to actually see which tasks must split or join.
We track both the time spent working on the tasks, and the time remaining to complete them. The remaining time allows to determine the progress made during the Sprint, and to anticipate whether we will be able to achieve the Sprint goal. We update the remaining time for the tasks, adjusting it (sometimes increasing it) on a daily basis.
The time spent is - supposedly- for micro management. It also gives the team a chance to get some feedback on the accuracy of the estimates - and to get better at estimating - and to show how interruptions prevent the team to work on the Sprint backlog and therefore, slow it down.
In the Scrum process, individual deliverable goals are called Backlog Items, and can be seen as bucket of tasks. The Backlog Items are prioritized by the Product Owner, estimated by the Team, first as a whole and then task by task. Content, scope, priority and estimation of the Backlog Items can be revised.
We estimate both the Backlog Items and the tasks in time units (days or weeks for the Backlog Items, hours for the tasks) and we apply a focus factor (ratio of time dedicated to work solely on the Sprint tasks) to account for time not spent working on tasks to achieve the Sprint goal.
With respect to time tracking, what you're looking for is a burndown chart.
Fredrik explained what a burn down is, without using the term. Essentially, you regularly reestimate the time remaining for a particular activity.
So to your question of whether or not we track time spent, not necessarily. Scrum likes to work with time remaining instead. (You could substitute hours with story points, the principle is the same, as Robert explained.)
To your second question of whether you can adjust your tasks and estimates, most definitely yes. Agile follows the 'reactive to change' philosophy; you prioritize what's most important to the customer.
However, some teams to prefer not to add/delete/re-prioritize tasks in a particular sprint once it's begun, since that is almost an ad-hoc way of working, and even scrum requires some structure and discipline.
The statement "thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks." is almost certainly not in the spirit of agile.
We use the Pomodoro Technique to track the time remaining. One of its advantages is that the amount of time spent is recorded in a disciplined way.
After estimating stories in story points, we estimate tasks in terms of pomodori, and use this estimate (which may be reestimated ad hoc) to judge the amount of time remaining. At the end of the sprint it's easy to see which tasks we originally estimated the least accurately and improve how we estimate in the future, due to the way we mark the number of pomodori estimated and completed on each post-it.
In terms of the sprint, the estimated hours remaining are just a measure of progress so we can see where we are burndown-wise. They're a clue to whether we're on track or not. The score that matters is story points completed.
By definition, an item is done when all of the tasks that need to be completed in order to fully implement that item have 0 hours left. What you need to track inside the sprint is remaining hours on remaining tasks. Not hours spent on a task. Why? Because our knowledge of how long something will take is imperfect and we gain little by trying to come up with a super-accurate estimate when we should be working on the product.
You are always allowed to add tasks under a sprint backlog item as you identify more work that must be done to fully implement the item, and you should update the remaining hours to completion daily (or set them to 0 once you've completed the task).
You should tell your VP that knowing when you're going to ship the product based upon your most accurate information (today) is far better than setting a number/making an estimate in the past and never updating it. This doesn't mean re-estimating user stories (don't do that until the end of the release), it means updating the sprint backlog with new tasks, and the best estimate as to when active tasks will be complete in remaining hours.
BTW, the way to work on accurate estimates is to plan your release using story points, create an iteration plan based upon your estimated team velocity, and then to continually update the iteration plan based upon the output at the end of each sprint. After a very few sprints you will get a very accurate idea of the actual team velocity, making it easy to forecast when you will ship your release with the desired scope... or what scope should be completed by the original ship date. Using actual project data from your current project to predict project completion is a software engineering best practice, because it is the most accurate way to make a prediction.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We started a project that will be managed with Scrum/XP. We wrote the whole product backlog upfront for evaluation purposes. We're making sure all stories are customer-centric and we're evaluating them by
story business value: MoSCoW technique - Must, should, could, would/won't have this implemented
story effort/complexity (= story points): 1, 2, 3, 5, 8, 13, 21, 100 - related to story complexity/effort rather than ideal days duration
100 story points may have some stories with Would/Won't have because they actually are bigger complex stories that will be broken down later if needed.
Calculated story importance is based on value&effort by not overlapping MoSCoW stories.
But without 100 point stories our stories so far (also broken down) has complexity between 2 and 8 which we think is an appropriate story size to avoid micromanagement. But some stories became related or dependant on each other. We have stories that may take more if done first, and less if some other story would be done before them.
Questions
Is it possible to adjust story points later on during development, as we can do with story tasks where we can re-evaluate them, add new, remove existing or is this not the case with stories? Because changing their complexity, will also change end date estimates based on planned velocity. What's the best practice in this case?
You absolutely can estimate your stories again and you should. The points are only locked when the team commits to them at the Sprint Planning Session immediately prior to the start of a Sprint.
One practice I've used is when doing the individual Sprint Planning you should evaluate each story again. The team learns over time and will become more accurate with estimates and identifying dependencies. Remember what goes into a Sprint is up to the team, the product owner defines the overall backlog. If the project is time bound don't try to make the estimates fit the End Date, if you do you are setting yourself up for failure.
Remember that with Velocity you start with a guess at what you can accomplish. It usually isn't until the 3rd or 4th Sprint that you hit identify a realistic Velocity that the team can manage. Yes this does mean that you may have assumed the team could deliver 20 points per Sprint and actually can only do 15 points. Yes that means delivery time goes out or stories fall below the cut line.
As for dependent stories you should work with your product owner. If the team talks to them you can usually rearrange stories. Most people are receptive to someone that tells them "If we do A now it will take the full Sprint, but if we do A later it will take 15% of a Sprint" that makes it pretty convincing.
A useful practice to try is scheduling the stories within the Sprint. During the planning session once all stories are validated and discussed the team pulls up a calendar and discuss when they want to have things done. By putting target dates on a calendar it helps to identify overlaps and dependencies between the stories. This can identify things that are serial in nature and may cause a Sprint to fail.
Hope this information is helpful.
From your explanation you're doing a great job already. Of course there will always be stories with a dependency. Some may not even have directly visible customer value; i.e. the initial effort to set up an architecture and some frameworks). But if you leave them out you'll create a lot of technical debt. If you can, I'd suggest that you try to make the equation complete and somehow show the relation between the tasks.
For instance:
- task 3 is 8 points if done after task 2, but 12 points if done independently.
This way the product owner will feel the pain of ignoring dependencies, but can still make a choice to do the most valuable stories first. If the product owner is sure that all of the stories make it in the next sprints, then you can steer to have them implemented in the most efficient order. For instance, by blocking items for which dependencies have not been fulfilled (i.e. you can only have the 'change my logo on website' feature after the story 'webenabled version' is completed.)
Good luck!
I can only describe my expirience.
When we were planning first sprint we decided that we could accomplish 18 points. So we took several stories and total estimation were 15 points. As I mentioned above we were making our first steps in scrum and that's why we decided that 3 unused points and form-factor 0.6 guaranteed our success.
But our estimations of each story were only approximate. We had also some dependent stories. And we didn't make plan of implementation of each story because we thought that it's unnessecary with agile methodology.
As a result we failed our first sprint with only 8 complete points.
Before our second sprint I decided that we should take something from old good simple cascade and iterative methodoligies (and I was a scrum-master). So, on our next spring planning to make correct estimations we planned each story (about 20 minutes per story), with simple diagrams, all dependencies, details of implementation and so on. The planning was difficult and it took 2 meetings.
But the second sprint was much better and we've done almost all (actually we've done all but with some bugs). I think that we'll take less form-factor in 3rd sprint and it'll be successful.
There are some patterns that would help you in splitting User Stories in a way that they would remain INVEST, which means you would try to save dependencies, size, testability and value in particular. You can read more about that here: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard is actively applying and improving them, and he is not alone ;-)
Just be aware that splitting and keeping dependencies (which is like creating a critical path in a Gantt chart) is going to trump the capability of the team to be creative, and to negotiate on those stories, and might also hide a "non-valuable-proposition".
HTH
ANdreaT
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
During our iteration planning, we frequently find ourselves in the same position as this guy - How to estimate a programming task if you have no experience in it
I definitely agree with prototyping before you can give a reasonable estimate. But the same applies to anything that needs a bit of architecture and design - but I'm not that comfortable doing all this outwith the scope of a sprint.
The basic idea is that you identify as many tasks as you can that you're confident of, and estimate these as normal. For those areas that you're unsure of then there should be two 'types' of task identified: Investigation & Implementation.
Investigation tasks are brief descriptions of work that you're just unsure of, for example "Investigate how to bind Control X to data". An estimate is provided for these.
The Implementation task is a traditional rough guess, probably based on the story points assigned, of how long you think it would take to implement the feature.
During the sprint, when the investigation tasks have been completed, the developer should then be at a stage where they have a much better idea what is going on. 'Proper' Tasks can then be identified, which take the place of the Implementation placeholder. In addition, further Investigation tasks may be identified at this stage, and the cycle continues.
In the above example, we start with an Investigation task at 7 hours and an Implementation task estimated at 14. Once the first Investigation has been completed, Tasks 1, 2 and 3 will be identified and estimated with some degree of certainty, where Task 3 is another Investigation task from which Task 4 and 5 will be identified at a later stage. As you can see, the first Implementation estimate had delivery of the feature within 14 hours - but the reality is it took at least 4 + 7 + 3 + 4 + 2 = 20. A third more than the initial estimate.
alt text http://www.duncangunn.me.uk/myweb/images/estimate.png
All thoughts are welcome - my gut instinct is this will fly - am I right or am I the Wrong Brothers?
Cheers!
What we do.
Some features involve new technology. We can't accurately estimate them. Period.
We make up a number. Based on a couple of things. How hard does it "feel"? Can we get by with some kind of "partial" or "just-enough" implementation?
If it's hard, then it's hard. It will be expensive.
If there's a lot of parts, with a kernel of goodness and some bonus stuff layered on, we have a possibility of putting just the kernel into a release, and setting other stuff aside for later. A very few things are "all or nothing" where a partial release isn't possible. In that case, we have to provide enough time for "all", and that gets expensive.
Our standard approach is to get stuff that works, and possibly defer things to a later sprint if we ran of out time because of unexpected complexities.
What you're calling "investigation", we call technical spike sprints. For stuff that's new, we make up estimate number to placate managers who feel it necessary to overplan things. Then we spike the technology. Once it's spiked, we can revise the estimates based on what we now know.
Actually, the implementation of the feature took 27 hours - you forgot the first investigation of 7 hours, so in reality the actual implementation took almost twice as long as the estimate.
There are two ways you can go on this:
Just make the estimate as best you can and potentially experience a blowout in your sprint and a declined project velocity (you should only do this if the feature is both urgent and critical); or
Schedule the investigation for this sprint and leave the implementation for another sprint - without an idea of how long the task will take, the Product Owner does not have enough information to make a decision about in which sprint to schedule it or even whether to do it at all. Only tasks that have been estimated should be included in your sprint.
The first choice means your sprint and project estimates are somewhat arbitrary. The second choice gives much more predictability to your sprints.
In your example, the initial investigation may be scheduled for Sprint 1 but without knowledge of how long the task will take the Product Owner can't decide how to schedule it. If you came back with an estimate of 200 hours the Product Owner may decide not to do that feature at all, or to delay it until Release 2 of the product. The estimate comes in and the Product Owner schedules Task 1, Task 2 and the investigation of Task 3 for Sprint 2. After estimating Task 3, Tasks 4 and 5 can be scheduled in Sprint 3 or later.
Estimating feature usually is complex task. After some time your estimation will become better. But good approach can be that you estimate features with the story points. Story point is abstract value (meaning agreed among the team) that express complexity of the problem.
You should assign the same complexity (same number of story points) to the features of the similar complexity. Then later on it is enough to estimate only smaller set of features (or looking at the historical data) and you should be able to estimate how much time you need.
Features with the similar complexity need similar time effort for implementation.