79
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 ...
27
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
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
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 ...
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, ...
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 ...
20
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 ...
19
If you do development work in the sprint, you should estimate. If you don't, then it's better you skip on providing your own story points estimates.
You can help your team with information and advice, and support them to reach consensus, but you should let the people that do the work perform the estimates, otherwise you might be influencing them in one ...
18
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 ...
18
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 ...
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 ...
18
This depends a lot on how the two companies involved in the contract negotiation operate.
You have to realize that there is always a cost of doing business, and somehow you have to recuperate it from the profits you are making. Think about your daily work, for example. You might work for 8 hours a day, but possibly you are productive and producing an actual ...
17
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
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, ...
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 ...
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 ...
13
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 ...
13
Two things jump out at me.
First, the end result of a Spike is not a shippable product. Spikes are used to learn, and do research. The end result is an answer to a question or finding some information or gaining knowledge in a given area. That doesn't mean that there's not an output associated with a Spike, but it's almost certainly not a shippable product. ...
13
Vertical Slicing is a Best Practice, Not a Framework Requirement
Your prerequisite tasks (by definition) must be prioritized over their dependencies, so a separate task or user story for C should be created to track it. The only reason this feels a little icky to you is that you're making at least one of the following implementation errors:
Allowing your ...
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
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 ...
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
TL; DR
Velocity is not a management target. It's an estimation tool, and you should be using it as one tool among many to help plan your Sprints. Don't treat velocity metrics as targets, or maintaining a given velocity as the primary goal of each Sprint.
Hours and story points have no direct relationship to one another. Story points measure relative effort, ...
Only top voted, non community-wiki answers of a minimum length are eligible
