147
Using points is one version of what is often called "Relative sizing." For a very highly recommended initial perspective, check out this video and then come back. Most uses of story point estimation limit you to the lower end of the Fibonacci series: 1, 2, 3, 5, 8, 13 because the goal is to group things of similar overall size rather than to pursue a highly ...
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 ...
39
I wouldn't say the points are better. This is a technique focused on a different aspect of estimation. It may turn out that your point estimation will suck more. Have that in mind.
When estimating in hours you focus on answering the question "How long it may take us?". So basically it's more or less guessing, based on your previous experience.
When ...
21
The essence of estimating in points is that it is based on relative sizing, whereas hour is an absolute measure. My 10 hours task could be your 5 hours task but we both would agree that creating a normal user registration page is smaller task as compared to creating a shopping cart module, so this approach reduces variability in estimates.
Give points ...
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 ...
17
We've struggled with this too. This kinda summarises our journey, that's not to say the same things will apply to you!
Design work is done in sprint
This used to be OK when we were doing long sprints (4 weeks) and there was time for some back and forth, between the designer, UX and Marketing about what the final design should be. Even in long sprints ...
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
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
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 ...
16
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
As always there is no simple answer to this question. I would say that you should choose what works best for you. However as you say working with hours doesn't work for you.
In my team it was the psychological aspect about working with points. When people are estimating in points they feel more comfortable, because there is no simple measure, that 1 point =...
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
If you have a bad reputation for underestimating, do you also overestimate as often? If so, you may not realise it - we're wired to notice the things we do wrong, more than we celebrate the things we do right.
If you're doing this, it may be that you're simply picking work with a high degree of uncertainty. You may even be underestimating because of this ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
