Permission to Size ScrumMaster?

When I first heard about Scrum one of the distinct messages I heard was of a planning meeting where all involved in the product – devs, testers, business, managers, etc – all sat in a meeting and played Scrum poker in order to agree on the relative size of the work.  This translated into a beautiful scenario where everyone involved bought into how much work is being done and at what rate as they were all jointly involved in the sizing of the work.  There was no frustration at the rate of progress as the velocity was understood and the sizing was communally agreed upon via conversation and mutual understanding.

This is possible a utopia.  But it is an interesting perspective on the sizing game and group buy in.  I’m not sure anyone actually does this.

In a previous post – The dual faces of Sizing – I identified two types of sizing that may occur on a Scrum project.  I avoided the question of who exactly was doing that sizing.  Is it the utopia of all stakeholders who care?  Or is reality, necessity or practicality different from the utopian dream?  And is that utopian dream even desirable?

1. Who sizes for release planning?

Ideally you want the entire team involved.

However you might be able to get good enough with someone who is both familiar with the new stories – possibly having been involved in understanding them and writing them – and who also is highly familiar with the team’s sizing and therefore can give a reasonable approximation as a team proxy.

If you do this, measure the changes so that you can understand the amount of change for future planning.  Metrics are your friend – if you measure, and if you use the measurements effectively to become more predictable in the future.

2. Who sizes what comes into a sprint?

Going back to the opening story – should the business people be involved in the relative sizing of the work that they will not be doing.  No.  Yes.  Maybe. Maybe not.  It depends.

Here are some options – and some ideas as to why it may be good or bad.

a) Only those that actually do the work have a say in the sizing

On the one side, sizing should be an activity for those who do the work.  They actually have to do it, so how can anyone not doing the work actually say anything about the size of it?

The complication of this model is who is “the team”.  Is the ScrumMaster in the team or outside?  Is the Product Owner in the team or outside?  Is the architect who writes no code but acts as an acceleration agent in the team or outside?  It becomes difficult to differentiate who is in and who is out.

The biggest pro is now the team has defined how big the work is.  They buy into the size of the work and they will be the ones committing to doing the work.  This model allows them to have the whole say as to what the work is.

I suspect this is what the majority of teams are doing.  It avoids some dysfunctions by not allowing them to be options (like overpowering stakeholders) and it fits into the ScrumMaster mantra of “Protect the team” and “Let the team decide”.

b) Everyone can come to the party

On the complete other side, collaboration is a key agile concept, including everyone in the process increases the common buy in and understanding of the impact of the work.  These discussions can allow for increased transparency and buy in to the rate of delivering the software.  This could be incredibly powerful for group ownership of the deliverable and allow those not doing the work have a say in the destiny of the project.  It allows them to feel like they can impact the deliverable by them understanding what the impediments and the time sinks are.  This can bring the discussion far closer to allowing the customer direct input into what they actually get – not only with the final solution but also the trade-offs along the way (speed vs features, etc) – which is a good thing.

The difficulty with this model is that significant issues can arise if the relationships with all involved are not of an equal level.  If the CEO is involved with sizing then s/he may significantly overpower or influence the process which may lead to the process becoming meaningless.  If you have a dysfunctional situation in your environment then this is the worst thing you can do as it can significantly impact the team buy in to the size of the work and could be a failure in ensuring the team is protected to do the work the way they feel best.

c) Everyone who has value to add to the conversation should be involved

Is there a middle ground between options a) and c)?

The complication with option a) is that it may exclude people who have valuable insights to offer.  If you exclude the Product Owner from the sizing activity you may lose the conversation that shows that the team has misunderstood the requirement that the PO is putting on the table.  If you exclude other individuals who have value to add, you may also lose their conversations that may help in identifying the full extent of the work.

There are variations on this model – perhaps you could have the PO and/or other involved parties provide the sizing after the initial team sizing.  This allows the team to understand what they believe the work to be – while adding in the additional conversation from the PO and other interested parties after the fact.  This two phase situation would only be needed if there is a dysfunction that allows the team to be overridden by individual power structures.

A dysfunctional example – minorities must have a say!

An example of this dysfunction could be a team with 4 developers, 1 tester, 1 PO, 1 ScrumMaster, 1 Usability expert, 1 document writer all sizing the work.  If the goal of planning poker is to pick the majority view, and the tester, PO, usability expert, doc writer and SM all are voting – and they vote an 8 when the developers are all voting a 13 – by the majority view the story is an 8.  But this may be a dysfunctional decision.

In an equivalent example, assume a team of 4 developers, 1 tester.  If they are the only people voting and the devs all vote 8 and the tester 13 – again, by the majority view the story is an 8.  This too could be a dysfunctional decision.

In both of these examples – the minority needs a say.  If a tester identifies that the testing of this item – their activity – is going to be a significant amount of work on a given story then they need to identify this and the team needs to acknowledge this in the form of discussing and perhaps accepting the tester’s sizing over their sizing as there are factors that they aren’t taking into account when thinking about the sizing.  This is the point of planning poker.  The key is conversation.  The ScrumMaster needs to facilitate this activity to ensure the voices of the minority are heard and not squashed.

So should the Product Owner size?

It depends…

If the PO is going to attempt to significantly influence the team – then no.  If the PO is using the voting opportunity to show up disparities in expectations – then yes.  The difficulty is to work out the POs intentions and to respond accordingly.

The other key reason for the PO to be involved in the voting process is to perhaps engage with a discussion on how we can simplify the implementation.  But that could be done with voting or as just a conversation around voting.

The key problem with a PO voting is clearly that they often are leaders in the organisation and wield more influence in the team and hence may cause problems as a result.  Manage that, and things will work themselves out well.  In fact it may empower the team more by having the PO involved and allowing the team to see that they can vote their way and not be overpowered.  It depends on the PO…

So should a ScrumMaster size?

It depends…

If the SM is going to reduce their ability to facilitate the voting in the previous dysfunctional examples then they should not be voting as their involvement could make them appear partial to a given outcome.

However if the SM is a team member – delivering software as well (which is not an uncommon formation in a Scrum team) then they may have value to add by voting with their team role hat on.

Another scenario that I can see is if the SM is the longest serving member of the team –who has domain knowledge and understanding.  Perhaps they were team members before they transitioned to the SM role, perhaps the rest of the team is newer than them.  In these scenarios excluding them from the sizing activity may lose valuable insights.

However in these scenarios the SM could come in with secondary questions such as – I thought it might be an 8 because we may need to integrate with the old email client which has a difficult monolithic interface – what do you guys think?

To close

I’m not sure the utopian idea of everyone group hugging and agreeing jointly on the size of the work in a meaningful way would occur in reality.  It could be a good experiment.  But it might be messy.

I have always sized as ScrumMaster because I’ve had good insight into the work that the team has been doing.  However in the current organisation that I’m in, I can comfortably sit back and not size as I don’t have the history and I don’t add value to the equation for sizing yet.  So for now, in my currently role, I won’t be sizing anymore and I’ll monitor how that goes.

I noticed most POs prefer not to size – or don’t take sizing too seriously.  Either way, that’s fine with me.

The key goal is as a conversation enabler to allow deeper understanding.  That, and as a metric to help measure the rate of progress in order to approximate the range of potential delivery dates of course!

Advertisements

A retrospective on a planning talk

I gave a talk at SUSGA on Thursday evening.  The talk was entitled Release Planning with Scrum: Controlling the Chaos.  My slides can be seen here.

I think the talk went well.  I think it was well received overall.  We did touch on a couple of topics that weren’t specifically under the auspices of the talk that I’m sure I’ll blog about soon.  But the content itself seemed to be understood and generated much conversation – which is largely the point.

I did learn a couple of good things

  • When I know my content, I’m okay at presenting.  This is good 🙂
  • Karen had a great comment of how to deal with sizing of epics when turning them into smaller stories. Simply generate only as many stories as fit the number of points. Once you’re over that amount – either cut stories, or admit scope creep.  (And I would add – measure to understand the growth)
  • I don’t necessarily tow the party line in my view of certain topics.  I’m sure I’ll blog about some of those soon to explore both my thinking and hopefully get feedback from others.  That interaction/conversation in my mind is largely the point of why I blog so I’m sure it will be fun.

I would do a couple of things differently

  • I should have written up bullet points on the points that each group brought up so that they could be remembered and blogged.  I intended to, but I only remembered half way through the discussion.
  • I would touch a bit more on release planning versus releasing software – i.e. when you’ll get something versus when something will be live.  You still want to plan to know in a ball park manner how long it will take to get something specific even if you release software into the wild every sprint.
  • I practised a lot – which is great.  But based on that practice I should have changed my slides as by the time I got to the presentation I knew all the points around the points on the slides so I could possibly have achieved less PowerPoint hell.  Perhaps next time I’ll create two sets of slides – one to practice until I know what I want to say.  And the other the cool image laden slides that I can talk about.  Something to think on.  I’m not presenter type so I’ve got lots to improve around this.
  • I suspect one or two people do release planning very differently.  I should have stressed that this is the way that I have done it, and that I’ve found success, but by no means is this a blueprint for the only successful way to do release planning.  Between the PMI comment (that this is “practical agile”) and the comment that the talk was good as I presented my content well – there were certain people who possibly think what I’ve been doing is overkill and maybe not agile…  but I’d love to hear what the other options are in helping stakeholders understand and take part in what is happening.

The interesting thing is I wasn’t nervous until the hour or so before the talk.  That is progress too. I’m starting to get better at this public speaking thing.

Thanks to everyone for the support and positive vibe of the evening.  I think it was great.  And hopefully it inspired some ideas, thoughts and conversations in the community that we are.  If that is all that happens, then I’m happy.

And thanks to the Yellowtail crowd who made it out.  It was really great to see you all again 🙂