76
Is Planning Poker Bad for Software Development Teams?
This is the wrong question to ask. Planning poker is a tool. Asking if planning poker is bad for software development teams is like asking if a screwdriver is bad for plumbers. If the tool fits the job then it's a good tool, if not, then it's not.
The real question you should be asking yourself is:
...
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 ...
33
With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I ...
23
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, ...
23
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, ...
23
The first thing you should do is encourage the team to bring concrete arguments.
"Things are more complicated than they seem" or "I dont think those complications are valid" are very vague arguments.
"I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, ...
22
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
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 ...
19
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 ...
19
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 ...
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 ...
16
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 ...
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 ...
15
TL;DR
Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework.
Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using ...
15
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 ...
15
Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to ...
14
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 ...
14
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, ...
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
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 ...
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
12
Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be ...
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
You can't be faulted for being confused. It is very common for organizations to try and directly match story points to a real-world measurement. This exactly defeats the purposed of using story points (and why I dislike Poker Planning for estimating).
A Story Point in simple terms is a number that tells the team how hard the story is. Hard could be related ...
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
