53
If at all possible, they don't.
They ask developers to estimate it.
Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks:
The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done
The people who do the ...
21
Let's start with obvious observation: the moment that we know least about a project is at its very beginning. Unfortunately, for fixed-priced projects it is also a moment when we usually requested to say how much it's going to cost, thus to estimate.
In such situation I would focus more on improving estimate quality than on choosing this or that estimation ...
20
TL; DR
Story points represent consensus within the team. The goal of estimating story points is not to provide the largest or smallest estimate, but to accurately reflect the effort required by the entire team to meet the "definition of done."
Lewis Carroll Does Scrum
Consider a story like:
As a practitioner of Extreme Dentistry,
I want to know how ...
20
TL; DR
Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, ...
19
TL;DR
Much of Scrum's value to an organization is in creating transparency. 100% agreement isn't the real point of planning poker; the goal is actually to narrow the cone of uncertainty around feature estimates as much as possible, and to make the level of effort and potential project risks of each story visible to stakeholders through their chosen proxy, ...
18
It's all about abstracting away from a false reality.
Points are better than hours because they force everyone involved, especially non technical stakeholders, to internalize that building your own software is not like shopping for features in a store.
For better or for worse, business stakeholders almost always want to know "how much will each of my ...
18
TL;DR
If your question is truly about how you can manage a project like this in less than two hours per week, the answer is that you can't. At best, you might manage some minimal status reporting.
Project Management is a Full-Time Job
Project management, when properly done, is a full-time job for someone. That doesn't necessarily mean 40 hours per week ...
18
Well the easy and probably not completely helpful answer is, agile requires a change in how the business plans. You fund teams, not projects.
That's not entirely helpful so let me try and bridge the gap.
The success of an agile project boils down to having a good backlog and dedicated teams.
If you don't spend time planning a backlog, then you'll never ...
18
Story Points Estimation and Hours Estimation have different purposes.
We use Story Points during Product Backlog Refinement.
Story Points are good for high-level planning.
When we make an estimation in Story Points we talk about the productivity of the whole team. During high-level planning, only the productivity of the whole team is what matters.
Story ...
17
Per the Cone of Uncertainty, you won't be able to get estimates that have deviations of plus/minus 10% until much later in the project, at least after requirements engineering is complete. For a more agile approach, you would be able to estimate the sprint within this amount of accuracy after detailing the requirements to be implemented in the sprint. For a ...
17
When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members).
The ...
17
TL;DR
Should velocity increase with time?
The simplistic answer is that a project's velocity should only increase until the team has developed a stable, predictable cadence that can be maintained over time. There are a few caveats, of course, but it's a solid rule of thumb.
Targeting an indefinite upward trend on velocity is a "project smell" that the ...
15
Research stories (called Spikes in Agile terms), should be:
used sparingly
kept short
always be time-boxed
Should we assign a time box (so many hours) for research stories or a regular point estimate?
Regular point estimate cannot be used mainly due to following reasons:
story points give out a measure of business value
points are used to calculate ...
14
According to Fred Brooks, author of "The Mythical Man-Month", the practice of adding more people to a project at the last minute may not yield the results you want. From Wikipedia, this is known as Brooks's Law:
"adding manpower to a late software project makes it later"
Software isn't like manufacturing. When I was a lumber stacker, it took me a little ...
14
Person-month is politically correct synonym for Man-month.
It's mean amount of work performed by the average worker in one month.
So, if:
project requires 12 persons-months of development time
all team members do only pure development activity (i.e. they are telepaths and they don't need to spend time for communication with each other). [note: this is not ...
13
Fixed price contracts and ambiguous scope do not belong together ...ever. You cannot go down the path of even saying clearly what you will do because no one knows what needs to be done. You cannot plan to handle it with change requests because a CR is a change to scope...and you don't have any scope.
This is a time and materials contract. This is not ...
13
I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved.
I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...
12
Firstly, you should be clear on the terms you are using. An estimate, which should be a range of results, is different than a target, which is a single number to which you are marching and which lies somewhere in the range of your estimate. So you are talking about targets.
The rule is easy: you break down your work to the smallest level that you need to ...
12
I'm going to assume that you are running one of the versions of Scrum in which there is both a "story point" estimation, done by the entire team, and an "hours estimation" done by the individual assigned the work. If it's not, and your only estimation is the story point one, this issue shouldn't arise because the estimation should be done by concensus of the ...
12
Not surprisingly, I hear that question a lot. The basic problem with the question is that Agile disagrees with the fundamental idea of a fixed-scope/fixed-timeline project. In the question you were asked, there is the assumption that the end date of a set scope is knowable and the problem is that we are bad at knowing it (estimating). That's not really true. ...
12
The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke.
See https://en.wikipedia.org/wiki/Cone_of_Uncertainty
11
TL; DR
Should we assign a time box (so many hours) for research stories or a regular point estimate?
You should do both. A spike (or "spiked story") requires both a time-box and a level-of-effort estimate, and is always counted as work.
Spikes Are Just Special User Stories
As one source states:
Like other stories, spikes are put in the backlog, ...
11
The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate.
The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint ...
11
First, remember that an estimate is highly unlikely to be 100% correct, so do the best you can with the information that is available to you.
Second, break down the tasks as far as you reasonably can, and get figures for similar low level tasks from other projects that have been done in the past. Don't worry if they are not identical, as long as they are ...
11
The art of giving a SWAG estimate
I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will ...
11
TL;DR
Velocity is simply a proxy for measuring team capacity over time, and shouldn't be used for historical time accounting. Always estimate based on the current level-of-effort and complexity, and this will naturally result in incomplete stories being reflected in velocity as drags on capacity.
Stories Shouldn't Carry History
Don't treat stories as ...
11
TL;DR
A common approach is to do a rough initial estimate of the Product Backlog using a sorting method like the bucket system, with variations described by ThoughtWorks or Mountain Goat Software. A few other techniques are also listed for reference at the very bottom of this answer.
The general idea of the bucket system is that you identify a baseline ...
11
Have Task Performers Provide Estimates
In agile frameworks (and even in sensible non-agile frameworks), project managers should never estimate work items themselves. Instead, the people who will actually do the work ("task performers") do the estimation!
To get the most realistic estimates, have the task performers estimate the time and complexity of the ...
10
Although probably not an intended feature, one of the benefits of using points from a manager's perspective is that tasks are measured by complexity rather than by time, which allows you to easily see who on the team works faster than everyone else. For example, you know that it takes person A 2 hours to do something, but takes 10 hours for person B (for a ...
10
First, it is a safe assumption that in software development industry you won't have precise estimates if you trying to plan 6 months ahead.
Second, despite of all the uncertainty of half-year-long estimates, and even more uncertainty attached to estimating incomplete or vague requirements, in vast majority of cases stakeholders need to know a general time ...
Only top voted, non community-wiki answers of a minimum length are eligible
