9 Replies - 664 Views - Last Post: 30 May 2017 - 10:56 PM

#1 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5824
  • View blog
  • Posts: 19,824
  • Joined: 05-May 12

Planning poker before the actual planning poker

Posted 28 May 2017 - 08:25 AM

Our team is taking over a code base written by a consulting firm for our company. During this transition period, our team as well as the consultants are participating in the planning poker for stories in the backlog. As you would expect my team members would tend to bid higher numbers than the consultants.

Our team architect would like my team to do a pre-planning poker planning poker ostensibly for my team to come up with more accurate estimates by the time be get to the actual planning poker. I'm oppsoing this move because it completely goes against the premise of the planning poker which is to prevent influencing the participants.

Any thoughts?

Is This A Good Question/Topic? 0
  • +

Replies To: Planning poker before the actual planning poker

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13389
  • View blog
  • Posts: 53,431
  • Joined: 12-June 08

Re: Planning poker before the actual planning poker

Posted 28 May 2017 - 08:39 AM

Why would there be a planning meeting for estimates from folk who are divesting themselves of the work? As in why are the consultants involved? You are taking over their work and seems.. odd.

As for pre-planning.. eh, I wouldn't go through a whole 'pre-planning poker' phase, but more of a campfire chat over the work coming in and thoughts on it all.
Was This Post Helpful? 0
  • +
  • -

#3 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5824
  • View blog
  • Posts: 19,824
  • Joined: 05-May 12

Re: Planning poker before the actual planning poker

Posted 28 May 2017 - 09:36 AM

The company's attitude is that as long as the consultants are getting paid, they might as well continue to write code and fix bugs.

When I started opposing, the architect backpedalled and said that the meeting was not for estimation but to get more clarity about the upcoming features...so that we are more aware about what we are estimating on. But strangely his last paragraph is about more accurate estimates. Hmmm...

As an additional facet to this, an unfortunate part of the company culture is that estimates are taken as gospel, not estimates. People are assumed to work nights and weekends to meet the "estimate". Completely against agile where if something goes over the line of the burn down chart it is just taken as an indicator that better estimation is needed.
Was This Post Helpful? 0
  • +
  • -

#4 Salem_c  Icon User is offline

  • void main'ers are DOOMED
  • member icon

Reputation: 2129
  • View blog
  • Posts: 4,196
  • Joined: 30-May 10

Re: Planning poker before the actual planning poker

Posted 28 May 2017 - 10:58 AM

So what constitutes "an accurate estimate"?

An accurate estimate can only be judged "accurate" by actually doing the work and measuring the actual time taken against the prediction. How is anyone supposed to make a decent forward budgetary and personnel plan if a bunch of made-up numbers are chaotically short of the actual mark?

If some bean counter takes "accurate" to mean "an estimate more congruent to the lower number provided by the consultancy", then that's simply the wrong way to go.

Do the consultancy's current estimates correlate with their previous estimates for equivalent work, or is that invisible to you? Are they simply under-bidding in order to look good to current blinkered management in the hope of retaining work (at which point the costs will go up again).

It seems natural for your team to come up with higher estimates in the beginning, since there is a lack of familiarity with the code base. As experience grows, the estimates will fall. I mean, that's the end game of the plan to bring in house right?

Where does your organisation fall on these categories?
https://en.wikipedia...del_Integration
https://en.wikipedia...mmaturity_Model

> People are assumed to work nights and weekends to meet the "estimate".
Do people get paid for that?

Because "to plan" should mean "on-time and on-budget", not "on-time, but we spent a fortune getting there!".
Was This Post Helpful? 2
  • +
  • -

#5 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5824
  • View blog
  • Posts: 19,824
  • Joined: 05-May 12

Re: Planning poker before the actual planning poker

Posted 28 May 2017 - 04:19 PM

Yes, the consultants estimates were spot on by the time they got to sprint 6. We are 40 sprint in now, and they have been consistently good.

I too considered it natural that our estimates to come in higher as they reflect the amount of uncertainty. That is how the bidding in planning poker is supposed to go.

I think that our architect did not like that the uncertainty is visible to the product owner, who by convention of a traditional planning poker, is also present. To me, one of the other aspects of the agile manifesto is that there is full transparency with all parties involved. I feel that we are going against this by showing false confidence in the bids.

The core team, until this architect came along, was operating at level 3. Since the time he's been told to work with my team, I feel like we are at level -2.

Alas, the this current project claims to be following the Agile methodology, but is strangely date driven. I've seen a lot of throwing more money at the problem to make the date. Good for the consultants who get paid overtime, but not so good for us on salary.
Was This Post Helpful? 1
  • +
  • -

#6 Salem_c  Icon User is offline

  • void main'ers are DOOMED
  • member icon

Reputation: 2129
  • View blog
  • Posts: 4,196
  • Joined: 30-May 10

Re: Planning poker before the actual planning poker

Posted 29 May 2017 - 01:00 AM

To reduce the uncertainty, individual story elements need to be broken down into 2 or 3 separate steps.

Instead of
S1 do A
S2 do B
S3 do C,

do
S1 ⅓A + ⅓B + ⅓C
S2 ⅓A + ⅓B + ⅓C
S3 ⅓A + ⅓B + ⅓C

You still end up with 3 stories complete at the end of 3 sprints, but individual smaller bits should be easier to plan and estimate.


The pre-plan meeting might be fine, so long as it sticks to purely technical matters to aid understanding within the team. Such as figuring out what a story element actually means, how the implementation might be realised, and how much code might be affected.

But anything tainted with 'estimate' should be strictly out of scope.

I wonder what your new architect is telling management, and why they seem to be trying to cover their @ss.
Was This Post Helpful? 0
  • +
  • -

#7 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5824
  • View blog
  • Posts: 19,824
  • Joined: 05-May 12

Re: Planning poker before the actual planning poker

Posted 29 May 2017 - 06:08 AM

I have a guess of what the issue is, but I'll get some kind of confirmation or denial when the architect and I talk 1:1 on Tuesday to hash out this conflict. My guess is that my team of about 6 developers is having an effective velocity that is equal to that of the consultants 2 developers. I suspect that our architect is not taking into consideration that those 2 are fully dedicated into development and advice roles while we 6 should be treated as being at best 50% allocated to the project because of the ongoing roles we have to keep other existing systems up and running. E.g. We were already DevOps even before the DevOps wave started going through the company.

Also nevermind that there is always the quote that "Velocity should never be used for anything else except capacity planning." Just like the way the company is twisting the way the Agile guide rails are meant to be used from simple guidelines/recommendations into requirements, and the concept of DevOps from a silo-less process to just faster throughput between silos, I think that velocity is also being misused.
Was This Post Helpful? 0
  • +
  • -

#8 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5824
  • View blog
  • Posts: 19,824
  • Joined: 05-May 12

Re: Planning poker before the actual planning poker

Posted 30 May 2017 - 05:37 PM

My guess about velocity was only partially correct. The main concern was the high bids due to uncertainty. The effect on velocity of the high bids was a close secondary concern.

The meetings will now not include any estimation component to it and only focus on getting clarity of the stories. I'm unsure how that is going to happen since he expressly wants only the devs to be in the meeting and the product owner not to be involved.

Anyway, it looks this came about out of embarrassment because all this makes it look like my team doesn't know what to do with the code base. To me, it's the truth. Why try to hide it?
Was This Post Helpful? 0
  • +
  • -

#9 Salem_c  Icon User is offline

  • void main'ers are DOOMED
  • member icon

Reputation: 2129
  • View blog
  • Posts: 4,196
  • Joined: 30-May 10

Re: Planning poker before the actual planning poker

Posted 30 May 2017 - 10:21 PM

> I'm unsure how that is going to happen since he expressly wants only the devs to be in the meeting and the product owner not to be involved.
But surely the product owner is going to be the best person to give clarity to the stories.

Or the other option is to bounce stories back to the product owner saying "what do this mean, can you clarify....".
Was This Post Helpful? 1
  • +
  • -

#10 jon.kiparsky  Icon User is online

  • Screw Trump (before he screws you)
  • member icon


Reputation: 10623
  • View blog
  • Posts: 18,179
  • Joined: 19-March 11

Re: Planning poker before the actual planning poker

Posted 30 May 2017 - 10:56 PM

Quote

Our team architect would like my team to do a pre-planning poker planning poker ostensibly for my team to come up with more accurate estimates by the time be get to the actual planning poker.


Um, no. The suggestion itself reflects that the team as a whole - meaning the people doing the work, meaning consultants and salaried folks - is not well-composed, and is not actually a team. The next thing that needs to happen is for the people doing the work to figure out how they can get on the same page about what it means to work on this project, what the goals are, and what in fact is actually going on here. A team that can't agree on what thee points means versus what five points means isn't going to be able to order lunch, let alone get any work done. I suggest an off-site meeting, with no managers, no project managers, no architects, nobody but pigs. So you can all get together and talk turkey, so to speak. Take a day, eat some food together, waste some time, and have as your goal to develop a baseline for estimation such that team members can all estimate on the same fundamental assumptions.
After all, it doesn't matter what your points are in the end, since the work that you take up in the next sprint will always scale to the points that you finished over the last three sprints, so you might as well just come to some basic understanding and get on with it.

Quote

An accurate estimate can only be judged "accurate" by actually doing the work and measuring the actual time taken against the prediction.


Eh, not exactly how I'd put it. I'd say that the estimates overall were accurate if the work promised was the work that was delivered. It's ridiculous to talk about planning points as a measure of time, so "measuring the actual time" is meaningless. What you're doing in estimation is estimating the amount of work that one ticket takes relative to another, and the law of large numbers takes care of the rest.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1