Search This Blog


17 January 2017

To use Story Points or not?

So you are in this agile transformation but, hell, you’ve been doing this for years and things like Story Points just do your head in. Surely by now we have something better?

Maybe. The obvious thing to replace story points is measuring throughput or cycle time. Eventually you can get back to your happy place of #noestimates and simply shipping a new customer request every few days.

We can talk about these later, but let’s reflect on where you are today and what simple and useful options you have in front of you.

Hint: Story points are probably still useful.

The problems you might be facing include;

  • Uncertainty down the line about when things will be ready and the related struggles managing expectations and downstream processes like marketing
  • Poor understanding of the requirements from the client/users
  • A lack of trust from management that your team is focused and doing the right thing
  • The team are subject to a tech lead who makes all the design decisions
  • A lack of commitment to the work due to a combination of the above issues

Story points – or more properly planning poker - are actually a useful tool to address most of the above issues.

  • Planning Poker is a simple idea that everyone can quickly get, so you get mutual understanding and consensus on an approach.
  • Planning Poker focuses primarily on shared understanding. The story points are simply a signal as to whether the team have shared understanding.
  • Planning poker is blind-delphi estimating, addressing the boas of following the leader
  • Planning Poker provides a structured way to challenge and explore requirements in a way that builds teamwork and collaboration with the product owner
  • Planning Poker focuses on a shared commitment to understanding and executing by the whole team; it enables better task breakdown and planning because the team grok what is needed better.
  • Over time Planning Poker will let you do regression analysis on stories. It will show you what normal story sizes look like, and the variation around them.
  • Story points get people away from estimating to what product owners hope to hear because they are focusing on the job to be done – understanding the story, and particular investigating it’s inherent uncertainty
  • You can reverse engineer story points into time estimates, over time; i.e. after you have a reasonable data set for your team

If you skip growing this capability, you’ll face other challenges;
  • When you start estimating you don’t have historical data to work with so you probably won’t be reliable.
  • You’ll keep using dates and you won’t get your opportunity to wean people off specific due dates
  • Planning Poker’s investigation discussions need to be had. If you don’t build the pattern of conversations, you’ll never build that skill of groking the requirements.
  • You’ll follow the tech leads estimates and fail to grow that skill in others, subjecting the team to a dependency on the tech lead’s design as well. This will further limit opportunity for growth in other team mates, as well as potentially keep usually silent but experienced voices out of the planning process.
  • Planning poker can gamify improving. You have a score, and you as a team work to improve your score over time. This is harder of you are always chasing deadlines or throughput targets.
  • Through using Planning Poker you’ll learn what a normal or standard sized story is for your team. Basically you defer growing the skill of story slicing until you master the skill of challenging and understanding the stories.
  • When learning to slice down to small stories, Story Points provide a good guide to your improvements, independent of environmental factors like wait times on other teams.

Once you can reliable achieve the following things, you should move beyond story points onto a more reliable estimate process like measuring throughput or cycle times, or you could potentially abandon size or duration estimates altogether. As long as you keep challenging the stories to understand what they will take, what assumptions are embedded in them and what uncertainties they hold.

2 January 2017

Hello Melbourne, here are your meetups

Here is a list of meetups based in Melbourne that could be interesting to the readers of this blog. The ones I am closely involved with are at the top.

The best ones :)

Lean, Agile, Systems Thinking (aka Management)
    Product and Project Management

      If you are travelling to Melbourne and want to share a story, get in touch with the organizers. If you are just wanting to connect with people and see what's up, please come along. These communities are all very welcoming.

      To the best of my knowledge these are all active groups at the time of publishing.

      I'll list out the technical meetups another time. 

      14 December 2016

      You agile people sure are a bunch of assholes

      A couple of weeks ago I saw this tweet.
      I can understand Melissa's sentiment; the model is complicated and overwhelming. And indeed, the industry is full of people who identify themselves with a solution. People can tend to be myopic about their favorite solution and treat it like a panacea.

      But that's not what is happening here. I'll explain shortly. First, I want to call out you assholes for what you did.

      Melissa's tweet was perhaps sarcastic, but nothing compared to what was tweeted in the hours that followed.  Chris' model was compared to the Pentagon acquisition process.
      He was accused of peddling consulting ware that propagate the problem,
      And of course the general sarcasm was strong with the crowd.
      Some moderate voices contributed to the discussion.
      But at the end of the day the overwhelming tone was of ridicule.
      What I saw was people piling on and participating in online bullying. There is a person that created that model. He doesn't deserve the frothy rhetoric you guys threw at him. I know Chris. He is a person just like you and I. Sure, he's resilient and didn't get too upset by what happened online, but not everyone can handle bullying as well as he can.

      Stop and think before you jump in next time.

      Furthermore, the criticism aimed at Chris seems to be misdirected.  His London Underground model is presented in a blog post that was also shared on the day and in the context it was originally presented in, it makes good sense.

      I wonder how many read the original article and saw the key idea giving context to the diagram;
      "We like to conceptualise Agile as a highly interconnected landscape of practices transporting ideas across zones to value. There is no perfect starting point, nor an express line or a direct route suiting all conditions."
      Essentially Chris agrees with the principles most of you critics threw at him; that each situation needs to be diagnosed and treated as a unique situation. He's just made the unfortunate mistake of highlighting the elaboration and complication of the agile landscape of 2016.

      I wonder whether the rain of criticism showered on Chris is because he has in fact revealed the irony of the industry.