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
Let's say the next sprint is 10 points/days. 3 developers are working to deliever an increment. each developer will have 10 points to complete.
The sprint started,
Original Estimate for each developer: 10
When sprin ended,
The Completed work for each developer: 10 but they still didn't make it and deliever the increment, so the Remaining work will be 3 more points for each developer.
to calculate the total numbers:
Original Estimation: 30 points
Completed Work: 30 points (Note: by Completed work I mean the developer really consumed one day working on the task but not necessarily get it done)
Remaining Work: 9 points (Note: Remaining Work is the extended points the developer need to get the task done)
How can I calculate the sprint velocity? I was thinking of: [(Completed Work - Remaining Work) / Original Estimation]*100
which is 70% working points of that sprint
Am I on the right track?
The velocity is the sum of the completed behaviours (or stories, if that's how you count it).
If they genuinely completed 30 points worth of stories, but during their work they created new stories worth 9 points, then the velocity is 30. However if they completed no stories and in fact got 70% of the way through 39 points worth of stories, then their velocity is 0.
And if they completed 22 points and the remaining 8 point story is now estimated as a 17 points story, then their velocity is 22.
Fractionally-complete stories do not count towards velocity. Not even a little bit.
Work spent doing an incomplete task counts not at all when calculating velocity. I know it sounds unfair, but this is the way it is. And it works. All that matters when calculating velocity is that the dev team has completely and utterly finished with the task. It's tested, it's in CI, the automated delivery system has its grubby little SSD wrapped around the software. Anything short of that does not count towards your velocity. If you count work done instead of behaviours released, then you are doing yourself and your customers a disservice. Don't forget that the 99% completed story from this iteration, which counts 0 towards your velocity, will be in the next iteration and will count towards its velocity. It all evens out in the end.
It's fine to re-estimate, or to create a new story from the existing one. But do not retrospectively change the points earned in the sprint. It does not help the team or the company achieve anything extra, it only inflates the team's confidence in themselves. Velocity, like all metrics, is a gross reduction of performance and it cannot be used to justify recent results. At best it can be used to encourage future endeavours.
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 understand that on the first part of your sprint planning, you would size the stories for example using story points and poker cards and then you estimate how many stories you can tackle on the next sprint. So let´s say you agree on working on 3 stories with a total combined of 18 story points.
Then you go ahead with the second part of the sprint planning and you start breaking those stories down into tasks. These tasks are now estimated using actual hours.
I have two questions:
1) How do you estimate the tasks in hours? do you use again poker estimating but with number of hours this time? how does the team agree on the number of hours for each task.
2) Once you estimate all tasks for the 3 stories you agreed for the sprint, you find out that the number of total hours combined for all tasks of all 3 stories is 90 hours for example. If your actual team capacity in hours is 75, how do you adjust your initial commitment of delivering 3 stories now that you realize that you don´t actually have the time to do it? Do you go back to your Product Owner (if he´s not there anymore) and tell them that you will be delivering 2 stories instead or how do you go about this?
Thanks a lot in advance for your help!
The tasks are not really estimated in hours but ideal hours. It's really hard to predict how many ideal hours will be available in a week, and it's generally not a good idea at all to infer the capacity on a sprint based on hour estimates. See for example this Scrum Alliance blog article
Story points and task hour comparison can be thought of as the comparison of the weight and height of an elephant. In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.
Normally, tasks are tackled by a single team member (or a pair), and thus they are estimated by them, and not by the whole team.
Furthermore, tasks are re-estimated daily: the number we look for is the number of ideal hours left to complete the task and not the total amount. So, it is a number that can go up or down, or remain constant.
Also, tasks can be added or removed during the sprint. It's actually pretty common to discover that initial plans change. It doesn't matter, as long as the total number of hours planned represents the best current estimate of what's left to do -- it's needed for burndown charts.
In conclusion, don't mind the hours. Use them to monitor progress during the sprint but not to determine capacity. This is what points are for and the two parameters are not interchangeable as it would seem.
In my experience, breaking into and estimating tasks is very useful and often underated. The idea is that the team become more and more accurate as time goes on through their sprints and they inspect and adapt. I have observed teams getting to the point where they end up completing everything in the sprint except for unforseen blockers (eg. Server down time). The idea is that the team calculate their capacity in (hours) and then calculate the amount of tasks they need to complete ( in hours). They can use this as a guide to make a commitment. There is a more detailed explanation here: http://www.pashunconsulting.co.uk/team_commitment_blog.html
You can also use story points to make a commitment but the general principle is that Story points are better for long term estimation (ie. for estimating when the project will deliver). Agile Estimating and Planning is a good book for this kind of stuff, as is the Scrum Mega Pack.
I guess an issue come from the assumption that you are able to deliver 18 points within a sprint. What looks not right when you do an estimation in hours later. So, commit to fewer number of story points initially and after several sprints you would be able to know your actual velocity in story points per sprint.
While breaking stories into tasks is helpful, it is not very useful to estimate those tasks.
The reason is that you will spend a lot of time doing these micro estimates and they will generally be inaccurate.
Besides, adding concrete hourly estimates forces work to fit in those estimates.
If you underestimated you might procrastinate, if you overestimated you might skip on reviews, unit tests or other quality practices just to fit the timeline.
So in general I like to stay with one estimate level -> the one that gives the velocity.
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 are a small group of 3 developers working on a project, using Scrum.
We are using 6 hrs/day/developer for capacity planning. My question is - if we are using 2 week Sprints and spend most of the day (5-6 hours) doing Sprint Planning, should we consider this time as part of the iteration (i.e that is why we are using 6 hr/day to account for things like this).
To me, this falls outside capacity planning as the 6 hr/day/dev is only to account for productive time doing normal things that a developer does on a daily basis....
You should do capacity planning in terms of stories. How many stories can you do this week? In this way you don't need to account for planning because it's not a story.
If your stories have sizes so different that you can't really plan sensibly without accounting for it:
estimate the stories in arbitrary "points" (basically size them one against the other) (good)
or
break your stories so they all become equally small (better)
In either case, you don't need to account for planning anywhere.
Sprint planning time should not be accounted in sprint iteration. But sprint planning should be completed in 2-3 hrs, not be done the whole day. Since you say your team is small consisting of 3 people, then ideally sprint planning should be completed within this time. So rest of the day is still available for sprint tasks.
I have tried a few different things, but here are the ideals that have worked best for me:
Think of dev work as 'closed door' costs: how long would it take if she was never distracted by emails, meetings, phone calls, lunch, beer runs, etc.
Identify, for your team, the ratio between 'closed door' costs and real life. Do your planning in 'closed door' (easier for devs to estimate) and use history to identify the ratio. This also allows you to try things out to lower the ratio (free soda/lunch delivery, email filters between 10am and 4pm, etc.)
Consider sprints as having a full day for planning, stabilization, and review. So for a two week sprint, use Day 1 for planning, Day 9 for stabilization, and Day 10 for review/retrospective.
So if you have 5 developers working 8 hours a day for a two week sprint, and you figure out that your closed door/open door ratio is 1.5, you have 5.33 closed hours * 5 devs * 7 days = 186.6 hours of work you can plan for.
If you have a strong SCRUM master (or other process leader) and push your team to have a complete definition of 'Done' (i.e. documented, tested, buddy built, and integration tested), you won't need a stabilization day, but it takes some effort to get there.
The benefit of this blended process is that you can use the open/closed ratios to understand each developers work habits (some are great estimators and have a ratio of 1, some people are pessimistic about everything and might have a ratio under 1).
No, you should not consider the sprint planning as part of the sprint iteration.
The hours the team spends during sprint planning is not considered when calculating the development team's capacity, as the time spent in this meeting does not contribute to the development of stories.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am used to thinking about time estimates in the way suggested by Joel Spolsky - that if a scheduled item takes more than 16 hours, it should be divided into smaller tasks. Now, I am implementing Scrum in my team together with Story Points based estimations. It seems to me that a good unit for a Story Point would be ideal man-hour, not man-day. If I used days, most of my issues would have estimates 1/2 or 1.
Do you have any idea, why the use of ideal man-days is mentioned most often in the Scrum literature?
It seems to me that a good unit for a Story Point would be ideal man-hour, not man-day.
This phrase sounds really, really strange, and not true. Where did you read that there is a correlation between Story Points and ideal man-day? Ideal man-days were maybe used in the early days of Scrum but, to me, Story Points (SPs) are a different thing...
Story Points are a way to to quantify the relative effort associated with a particular Product Backlog Item (PBI) which is composed of multiple tasks. Some teams use numeric sizing (i.e. a scale of 1 to 10) to estimate the "size" of a PBI, others use t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), some use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc). And by the way, did you notice that SP are unit-less?
If I used days, most of my issues would have estimates 1/2 or 1.
So what? That would just mean that you have small PBIs, which is not a bad thing (at least not for the most important one). But don't forget that there are theoretically two level of estimation in Scrum: the Product Backlog level, in points, and the Sprint Backlog level, in hours. As I mentioned in the previous paragraph, PBI are composed of tasks and they should be split into tasks during the second part of the Sprint Planning Meeting. And tasks are then estimated in hours and the 16h rule applies here: a task should not exceed 16h. If it does, it is too big and should be split into smaller tasks (because we are too bad at estimating big things).
Do you have any idea, why the use of ideal man-days is mentioned most often in the Scrum literature?
This is outdated anyway. Things might change in the future but the current consensus is to estimate in unit-less points. Points are entirely decorrelated from any time unit and this is intentional to avoid any mapping with real world unit, work capacity should be measured with the velocity (the amount of points a team can achieve in one iteration).
Estimating at the hour level is too fine-grained. It also will tend to drive to over micro-management, which is somewhat antithetical to agile principles.
If I have four tasks, each estimated at a half day, I can be relatively confident that in two days I'll have a good handle on them.
But 16 1-hour tasks? I have much less confidence in those being done in the same period of time, as any one of the tasks is subject to way too much variability.
The purpose of story points and the estimating game in general is to effectively judge velocity over several sprints.
So it doesn't actually matter what units are used to estimate, so long as everyone on the team estimates in the same way, and the same units are used at each estimation session.
It's also very important to make sure that different teams don't try to correlate their story points. What I think of as a story point won't necessarily be what yours is.
So - I can't provide an answer other than "go with what seems appropriate".
Googling for "scrum ideal man hour" gives 6500 results while "scrum ideal man day" gives 10000 results. Not that big a difference. I haven't noticed a bias towards either in the literature.
Nothing really valuable rarely gets done in less than half a day (min. task duration) or even a week (min. sprint duration).
Estimating in hours can give a false sense of accuracy. Even though 5 ideal man hours is precise, it's probably not any more accurate than 0.5 ideal man days.
Ideal man units also convey the notion of mapping to real world similar units such as hours or days. The mapping is rarely straightforward. That's why many agilists prefer unitless story points as a task size measure. Team velocity metric then does the mapping from abstract size estimates to real world time.
If you're following proper Agile practices, with full unit test coverage and the red-green-refactor cycle, there are a vanishingly small number of meaningful tasks which will take less than half a day. Also, using days counteracts the developers' tendency to underestimate the time required for a task. And of course, it's better to over-estimate times and over-deliver than to under-estimate and under-deliver.
I don't know but I'm prepared to speculate that this is because the "standard" scrum length is 30 days. If you're planning to do work in blocks of 30 days then you're going to need coarser units of measurement than if you had a sprint length of 1 or 2 weeks.
Most of the scrum implementations I've seen have spring lengths of 1 or 2 weeks - so counting "ideal hours" is more useful because the relative task sizes are smaller.
As far as a relative measure of effort is concerned and assuming you're using scrum to develop software I'd count the number of separate source code commits you could make if you developed each task cleanly and use that as a measure.
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
with agile estimating, is it true some say to choose intervals like 1/2 to 1.5 days only?
It tends to be a good rule of thumb (agile or not) that your tasks should be broken down into at most 1 - 2 day increments.
The idea is that if you have larger chunks than that then you haven't broken the task down enough and you will more likely miss the estimate and miss it by larger amounts of time than had you broke it down. Often when you break it down you discover your initial estimate was off and since you have broken the task down into more concrete tasks your estimate is now more accurate, more trackable and meaningful.
For tasks that are coming up on your to do list soon you should pay attention to this but for long range planning where you haven't necessarily thought out the feature in detail I think larger estimates / tasks not broken out for the feature is OK.
Here's a link to Joel Spolsky talking about this. Take a look at item #5 about half way down the page.
http://www.joelonsoftware.com/articles/fog0000000245.html
In my experience, any estimate that's longer than 2 days is probably hiding serious work that should be broken down further. Such estimates have a very high probability of going over. Try to break everything down into smaller chunks so that no individual chunk costs more than 1-2 days.
There are advantages to keeping the estimates short. It forces you to break up large tasks into small, discrete tasks that can be measured and discussed quickly, which helps promote the entire Agile development process.
That being said, I almost never keep a "rule" as a hard and fast rule with things like this. I'd say this is a good guideline, however.
My team consists of junior programmers (university students) and we've found that it's generally easier if we break all the large tasks down into a bunch of smaller ones. It involves more forward-thinking but in the end we are more productive and can it's easier to evaluate our progress. It also brings a sense of achievement when you have something completed at the end of the day.
I would agree with that guideline. Anytime I have ever taken on a 5 day task, it has degenerated to a three week nightmare. Large estimates indicate you didn't learn enough about the problem up front to know what is involved, because if you had, you could have found ways to break it up better.
I don't agree. If a team's iterations are two week long, the 10 days mean that 1 day would be spent for iteration close (show & tell), iteration planning and tasking or planning poker.
When playing planning poker, a team either geometric or Fibonacci progressions for estimates. For example, cards would contain values such as 1, 2, 4, 8, 16 or 1, 2, 3, 5, 8, 13. Each number reflects the number of days of development for a pair of programmers.
For each card, once discussion has occurred, each member simultaneously plays the card that reflects their estimate. If the majority of the team converges on the same estimate, the estimate is accepted. If there is much variation in the estimates, further discussion occurs (members explain the reason for their estimates) and another round of voting takes place. This occurs until consensus is reached.
If a number greater than 8 is picked, then the card is deemed to be too big and the card is refactored into at least 2 smaller cards. The reason being is that such a large estimate indicates the card is too big to be completed in a single iteration and any estimate is very likely to be inaccurate.
Using such a method brings commitment from the team members to delivery all they have committed to and for a new team the estimate become so accurate that carry over of cards soon become a low risk.
A very good post about agile estimation and planning you can find on the blog of agile42: Just enough, just in time
A lot of good answers here, so I'll play devil's advocate and approach it from a different side.
There's a possible problem with breaking down things into very small estimates (# of hours) when doing things such as release planning. David Anderson discusses it in his (excellent) book Agile Management for Software Engineering.
Basically, the idea is that with a task that is very small, a developer will pad his estimate by a fair bit (say, turning a half hour into an hour, or doubling it) because of a certain amount of ego that would be bruised if the developer failed to complete such a small task in the estimated time. These local buffers add up quite a bit and result in a global buffer that's far bigger than it needs to be.
This is less of a problem if you stick with .5 days as a min - it's basically assumed that there's some buffer in there, so you won't need to pad it any more.
I feel there is a bit of mix of information and overlapping in this thread... allow me to make my point :-)
1) The Fibonacci sequence, that is very much use through the Planning Poker technique from Mike Cohn, is about estimating "Complexity" of User Stories, which are - as Cam said - normally written on cards, and entail more than one task, at least all of those which will be needed to make a Story shippable (Ken Schwaber, Alistar Cockburn, Mike Cohn...)
2) The tasks that are included to complete a Story, are normally estimated in Ideal Hours or Pomodori (Francesco Cirillo, "The Pomodoro technique"). If you estimate in Ideal Hours normally the rule of thumb is to keep them between 1/2 day (3 ideal hours) and 2 days (12 ideal hours) of work. The reason for this is that doing so the team will have more qualitative status information by having at least every two days a team member reporting a Task as done, which is much more "valuable" than a 60% done. If you use Pomodori they are implicitly "timeboxed" to 25 min. each
The reason to keep tasks small comes basically from the "Empirical Process Control Theory" for which through transparency and regular inspection & adaption, you can better check the progress of your work, by quantifying it. The goal of having smaller tasks is to be able to clearly describe and envision in details what will be actually done, without adding too much of "guessing" given to the natural uncertainty deriving from having to predict "the future". Moreover defining an outcome and a shorter timebox allow people to keep the focus with enough "sense of urgency" to make it a challenging and motivating experience.
I would also catch up the point of the "motivation" and "ego" - from Chris - by adding that a good way to have people committed and motivated is to define the expected outcome of a task, so to be able to measure the results upon completion, and celebrate the success. This idea is encapsulated in the Pomodoro Technique, but can be achieved also using ideal hours for estimation. Another interesting part of the Pomodoro Technique is that "breaks" are considered "First Class Citizens" and planned regularly, which is very important especially in creative and brain intensive activities :-)
What do you think?
Best
ANdreaT
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Having used "days" as the unit for estimation of tasks in Scrum I find it hard to change to using Story Points. I believe story points should be used as they are more comparable to each other - being less dependent on the qualifications of whoever addresses the task etc. However, it isn't easy to make a team start using Story Points when they're used to estimating in days.
So, how to make a team change to Story Points? What should motivate the team members to do so, and how should we apply the switch?
When I switched to points, I decided to it only if I could meet the two following points; 1) find and argument that justify the switch and that will convince the team 2) Find an easy method to use it.
Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.
Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.
Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value
If you want to change to using story points instead of duration, you just got to start estimating in story points. (I'm assuming here you have the authority to make that decision for your team.)
Pick a scale, could be small, medium, large could be fibonacci sequence, could be 1 to 5, whatever pick one and use it for several sprints this will give you your velocity. If you start changing the scale from one to the other then velocity between scales is not going to be comparable (ie dont do it). These estimates should involve all your Scrum team.
Having said that you still need an idea of how much this is going to cost you. There arent many accountants who will accept the answer "I'll tell you how much this is going to cost in 6 months". So you still need to estimate the project in duration as well, this will give you the cost. This estimate is probably going to be done by a senior person on the team
Then every month your velocity will tell you and the accountants how accurate that first cost estimate was and you can adapt accordingly.
Start by making one day equal one point (or some strict ratio). It is a good way to get started. After a couple of sprints you can start encouraging them to use more relative points (ie. how big is this compared to that thing).
The problem is that story points define effort.
Days are duration.
The two have an almost random relationship. duration = f ( effort ). That function is based on the skill of the person actually doing the work.
A person knows how long they will take to do the work. That's duration. In days.
They don't know this abstract 'effort' thing. They don't know how long a hypothetical person of average skills will require to do it.
The best you can do is both -- story points (effort) and days (duration).
You can't replace one with the other. If you try to use only effort, then you'll eventually need to get to days for planning purposes. You'll have to apply a person to the story points and compute a duration from the effort.