Agile Forest

Find your path to agility with Renee Troughton

One of the first few comments to my partner after I touched down back into Brisbane last night was ‘Gosh I’m buggered. It’s been such a long week!’

He smirked at me and shyly commented ‘Monday was a public holiday. And you still have to work tomorrow.’

Was it really just two days? It felt like a whole week. All those late nights, lots of preparation, stress of going far out of my comfort zone and a hotel room only three floors away from a night club must have really pushed me hard!

I’m hopefully not going to write a long blog about all the ins and outs of the conference. I’ll let Craig do that as I saw the mountain of notes that he took and I’ll later take the lazy path and just link them. So what high level observations do I have:

  1. Lots of people. Apparently over 650+. But as far as passionate people, it very much seemed like a small group. Watching twitter there was some movement but not a lot, maybe 20 or so consistent twitterers (is that a real word?) Now there would have been an element of passion to attend in the first place but there felt like little zeal.
  2. Keynotes. I had seen something similar for Alistair Cockburn’s presentation before, probably on his blog, so there wasn’t much of a surprise there. It was the first time seeing Rob Thomsett and I had heard lots of people rave about it. I felt the raves were justified – his presentation was passionate, energetic and fun, albeit not covering the topic I thought it would. Side note Rob – the website you linked has broken pages *everywhere* in it. Jean Tabaka had some very cute ideas and some interesting links to books and websites. Unfortunately the links quoted weren’t right, but I eventually found some of it at http://www.gogamestorm.com/ and http://innovationgames.com/. I didn’t get to see too much of Martin Fowler as I left a little early to go back home.
  3. Key themes. Its all about teams. Agile isn’t a methodology – its a significant culture upheaval, a revolution.
  4. Best quote: Every time some does a Gantt chart a fairy dies.
  5. Most relieving moment? Finishing my presentation! How mean was it making me be stressed the whole conference leaving it till the end? But seriously, I am so happy I did it and it was a considerable personal stretch. My presentation aims fulfilled – to have the most ‘out there presentation’, only stage jumper, getting through it without passing out. I wanted to be energetic and funny but I also wanted people to be able to take at least one thing out of it. Hopefully some people took away a better understanding that their transformational pattern actually has a name, behaviour and risks associated with it.

Thanks to my Suncorp ‘hood’ for your support on the day!

Okay so I don’t get asked this question enough but feel a need to justify it to some extent because I am tremendously passionate about it.

Why am I, an Agile Coach, so fascinated with MMORPGs (Massive Multiplayer Online Role Playing Games)?

At its heart the reason is fairly simple – because behaviour is unconstrained, and unconstrained behaviour makes for some very interesting human nature observations.

For those without much of an understanding of MMORPGs let me digress for a moment and describe them a little. You may have heard of some of them – World of Warcraft, Everquest, Second Life, Eve, Rift, Warhammer, the list does go on a while. Within these games people play on a server; sometimes there are hundreds of servers for the game. On a server can be tens of thousands of people playing. As long as a player is online on that server you can see them in front of you (assuming they are standing in the same virtual section of the virtual world). You can interact with them and others in the virtual world around you. You can also interact with virtual computerised characters inside of the world.

The motive for interaction is to ‘progress’ or ‘advance’ in the world, ie become an expert in what your chosen direction in virtual life is (sounds familiar right?). Once you reach this expert layer you can then tackle hard projects called ‘bosses’.

Now these ‘bosses’ don’t just fall over when you talk to them. Generally you won’t be able to defeat them by yourself. Depending on the conditions that have been setup for the boss you might require four other players or even up to thirty-nine other players to use all of their expert skills against the boss. In a situation of you and another nine or more people working together it is not a simple matter of doing one expert action over and over. In fact, the level of complexity needed to defeat these bosses requires amazing levels of co-ordination that would make an average person unaware of the domain of MMORPGs boggle.

To put it into content, one boss might take a coordinated effort of twenty people thirty hours before he is defeated. This is thirty hours of complete concentration where a single second of failure from one person might result in a total group failure.

It is in this environment that I find MMORPGs fascinating –

  • What incentivizes individuals to spend hour upon hour with people they don’t like to defeat these bosses?
  • How do these teams form where there are no real world boundaries constraining them?
  • How do these teams reach peak performance when there is no body language to read?
  • With absolute anonymity how to people behave differently than they would in the real world?
  • How does a culture form inside MMORPGs?
  • How safe to fail is it when a single error from one person might result in significant disappointment of nineteen other individuals?
  • How does retention and recruitment work when there are no legal constraints on a system?
  • How does virtual corporate purging and takeovers work when there are no legal constraints on a system?
  • How does hierarchy and leadership naturally form and work optimally?
  • Do similar problems of Manager vs Leader exist as in a real world business domain?
  • Does storming, norming, forming, performing fit?
  • How does burnout occur for highly motivated people?

But the most fascinating element is

Are MMORPGs the future of our world and consequently the unconstrained nature of them?

I predict the business world to change much in the next ten to twenty years. I predict a world where white collared workers conduct their activities from home in a virtualised business environment where they can virtually walk up to their team member (who might be physically in a different country) and have a discussion/collaborate on some work together. Each day we are inching closer and closer to this, but this will be a virtual world where you sit in many realities at once and that excites me tremendously.

What we are learning today within Agile I feel will be very important for the virtual world of the future.

This blog entry is dedicated to that vision but is also a nice little wrap up for some posts that I will do in the future about this relationship. Expect the dot points remarked above to be answered in future posts.

I had the lovely pleasure tonight to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was “Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.

On the first failure mode I felt a little shaky. It was called ‘Checkbook commitment’ and was pitching failure where the Agile Champion is just a Sugar Daddy (my words) –  all money but no heart. I don’t disagree with this as a failure mode but feel it goes much further. To have a Champion in the first place is a good thing. One failure mode would be that one doesn’t exist; another would be that their expectations are unrealistic and they pull the plug too early in the piece to reap the reward, or one that doesn’t stand up for the framework and lets governance bog it down with unnecessary requirements. The failure is in several layers of the Champion not necessarily that they are only a checkbook.

Then failure mode two hit: Your organisation does not support change. My faith was getting weaker with immediate thoughts as to whether this was a cop out statement. What organisation DOES support change? If an organisation was supportive on change then surely Agile Implementation would be a no brainer. This is why cultural change takes an average of seven years and without a doubt Agile is a significant cultural shift for most organisations.

Now in fairness Jean had incredible jet lag and sleep deprivation so maybe the words didn’t come out right. When the closing slide was done I looked at it curiously – failure mode two was renamed to “Your organisation does not support learning” – was the initial slide a typo or the recap was the typo or did I just fail at paying attention probably and mis read it? If the point was supporting learning then maybe I could see that as a failure mode, but this is probably the only point in the whole presentation I wasn’t sold on.

There were further comments that occasionally peaked my interest. There was a reference to ‘insight’ and I felt that this had synergy with Alistair Cockburn’s recent post of reflective improvement frameworks.

Another point was made about servant leadership and this one really made me think hard. If we are trying to achieve a servant leadership environment – is the Scrum Master/Iteration Manager role counter-intuitive to this? Is the role we seek more really an Agile Coach rather than a Master/Manager role. Perhaps just the titles are bad, but all too often I have seen teams not take on collective ownership of the story wall, not take ownership of helping to facilitate retrospectives. I have heard many SM/IMs call the role an almost ‘administration’ role rather than a coaching or mentoring role. Maybe we are doing ourselves a dis-service in the furtherment of Agile by continuing with the Scrum Master/Iteration Manager terms?

On the recent topic of PMOs Jean talked about how a PMO isn’t there to enforce practices. I think I am still in two minds about this. I have re-organised a PMO so that its key function was to ensure that prior to senior executive approval of major projects the right IT people (and by right IT people I mean the real workers) were engaged with the right business people (end users or those that truly knew the business benefits and drive) met together and both agreed that they got just enough detail that they needed to proceed to the next step and that the value was worth the effort. In essence, they were there to ensure that effective collaboration was done. Prior to implementing that change executives would approve projects with no IT input to estimates or timeframes or estimates were changed (read dramatically cut) from what the IT group provided.

Take the presentation as a whole – 12 failure modes. What if a PMO’s function was to ensure that those 12 failure modes did not occur; I wonder if that would be considered worthwhile.

I loved the idea of walking into a retrospective and asking for a confessional (sorry Jean I took this idea a little further). Imagine asking a team that hadn’t performed a retrospective for a while and asking them to start their brainstorm with ‘Hi I’m Renee. It’s been five weeks since my last retrospective”.

I loved the concept of Servant Leadership as “I raise IQ’s for a living”.

I loved the point that performance bonuses are not beneficial to Agile (I’ll probably tackle this on my next blog as it has been mulling around in my head for a few months now and I will be presenting my vision on this when I present next week at Agile Australia).

I can’t recall anything mentioned about Definition of Done on the testing related failure modes but it was on the recap slide (maybe a typo again?).

All in all I got probably 5 takeaways that really made me ponder so A++ to Jean for the presentation, for making me think, and doing it whilst incredibly jet lagged!

A fellow coach, lets call him Dr Evil, was recently describing the fun that he was having on an Agile coaching assignment.

He was tasked to work with a small PMO (thats project… or in this case Program Management Office) among a number of other teams. He put on a cheeky grin like Dr Evil and I saw that he was up to mischief.

Now most coaches when faced with a PMO to work with would begin to educate those involved in the PMO how the PMO evolves to be a supportive function under Agile. Within Agile, a PMO might do a very small portion of governance and might help find resources for certain roles such as a supportive Project Manager, but the concept of a ‘reporting’ function would no longer exist or is simplified to such an extent that only a small number of resources are required.

Dr Evil is not like most coaches. This is a fact that he prides himself on.

Some coaches are supportive, some are direct. Dr Evil likes to think out of the box .

Problem of context: this PMO wanted to have a large degree of say as to how the Project Managers in the Program should be running their work. This behaviour was very anti-Agile, directly reducing the empowerment that the Project Managers should have.

Dr Evil’s solution: Load em up baby!

Dr Evil not only embraced what they were doing, he was actively giving them more… and more… and more. He has been happily tracking their PMO meetings and plotting on a graph the time that the meetings take. This graph is currently on an exponential rise. He hopes that at some point in time (soon) they will break under this ever booming pressure and plead for the Project Managers to make decisions, thus finally giving them the empowerment they should already have.

The current most inane decision sent up to the PMO: desk by desk seating allocation of 80 personnel.

Stay tuned to see how long they take to break, good luck Dr Evil!

Ever had that moment whilst Agile Coaching when you just want to /facepalm but you know professionally you can’t.

Here is a list of my more notable moments over a few years (sufficed to say this is not all of those moments):

  • A Standup where the Project Manager stood at the front near the story wall and one by one directed his hand to each team member asking ‘So what did you do yesterday?’
  • Where I had to explain to a CIO of a 400 person IT group what the difference between a Portfolio, Program and Project was (no, he really didn’t know)
  • Where I kicked off an Agile Process Improvement Project that required the IT Leadership Team’s involvement of requirements, setup the initial scoping workshop and was told that it was the first time ever that the Leadership Team had sat in a room together.
  • When I informed a team that we were going to invest in training them and received a reply ‘Why? If we are skilled then we would just get a job elsewhere.’
  • A Project Manager that Gantt charted over 500 stories across six months of work onto a wall and then continued to ask the team on Iteration ‘x’ why they weren’t working on the stories on the Gantt wall.
  • COTS implementations run Agile where Business Process Transition Analysis was not in scope at all. Apparently people figure customisation is better than configuration + process change.

What are your biggest /facepalm moments?

The 80/20 rule is not an Agile concept. It would be considered a super belief applicable to many management streams and yet its relevance in the sphere of ‘Agile’ is pretty high.

The mathematical basis is from the Pareto’s Principle that was further expanded by Dr Joseph Jurin. Jurin observed that 80% of value was earned through only 20% of work.

We take Jurin’s observation and apply it strongly in Agile – always ensuring that the highest value work is done upfront. In this respect if you delivered 20% of the requirements then most of the business value would have been achieved and you can ship vastly earlier than needed to begin reaping reward.

Heuristic as it applies to Agile #1:

The 80/20 Rule does not apply to Quality. When you write the acceptance tests that you will qualify the story against you cannot stop testing after 20% of the tests are done.

Granted that 80% of the testing’s value might be in 20% of the tests this isn’t something you can be half-hearted about. A story is done when all of its acceptance criteria are met not when 20% is met.

Heuristic as it applies to Agile #2:

The 80/20 Rule applies to the initial upfront workshops when a backlog and common consensus amongst the team is being formed.

This ties in closely with the manifesto value “Responding to change over following a plan”. Why overbake the backlog when in all likelihood it is likely to change?

Heuristic as it applies to Strategic Development #3:

The 80/20 Rule applies to the generation of a strategic vision or any other team consensus related activity.

We expect an agile project that has a six month end delivery date to change often, so why don’t we expect a strategic vision to be the same, especially as they are usually set at the three year mark.

When pondering the above recently the third heuristic is the one that made me reflect. After some recent team days we spent quite a bit of time in the strategic zone or in general consensus activities. We all knew the 80/20 rule and yet we didn’t follow it. The big question was why?

Was it because Agile itself encourages collaboration and everyone to have a voice? Was it because these sorts of activities are rarely revisited with most teams only doing them once a year and hence there is a strong push because it won’t be adjusted for a year? Or was it purely team dynamics that make the 80/20 rule so hard to achieve?

When I first taught planning poker seven years ago I used to use the phrase ‘Can you live with it an move on?’ if consensus wasn’t reached after two minutes of discussion. My reflection over this reminded me that I haven’t used that phrase for a very long time and probably need to bring it back. I have strived for collaboration but in doing so neglected the value that wasn’t being achieved.

If someone had said on those team days (or especially put up a poster) saying “80% of the value for 20% of the effort” and “Can you live with that?” I probably would have faught less.

A friend of mine recently posted an interesting blog promoting that agile does not require a compliance framework and asked for some review feedback. As I began my tirade back I realised that it wasn’t really feedback, but more an alternative view of the blog and vowed to post the reply to it as per below. I would like to note that in essence I don’t disagree with the post but wanted to present a devil’s advocate perspective.

Although agile is not a prescription my question is “when does it no longer become agile”  – at what point does a project shift away so significantly that it dives into the realm of chaos?
 
Is it when it doesn’t follow all values? Is it when it doesn’t follow 50% of principles? Is it when x,y,z isn’t done?
 
Why does this matter? Because I’m sick of Agile being tarnished with the “is bad” brush when projects are only following chaos.  (You only have to read up one more blog post to see that others feel the same way.)
 
I’ve seen plenty of waterfall projects succeed. I’ve seen plenty of them fail too, but they failed not predominantly because of waterfall but because they fell into chaos.
 
We are following the same pattern, just with a new methodology.

Over ten years ago I vividly remember the first moment I saw ‘Safe to fail.’ I was working for a large scale telecommunications organisation. Most of us working there were pretty young. With our youth came inexperience. I learnt that through a project re-assignment I was going to have a new manager and was anxious of what he was like. This was until a valued friend chipped in and regaled a story.

He told me that he had once reported to this manager and that I had nothing to fear. He recalled where he was once working on a email server and had setup a rule on the server to bounce an automated reply to not contact the server directly if an email was directly sent to it. Much to his horror he walked into work one day to find that the whole telecommunications network was crippled and this his server had been a strong part of the cause. It turned out that another automated server sent his server an email and the two of them began a bouncing war to the tune of over 10,000 emails being bounced per second between the two of them.

His manager once removed wanted heads to roll but his manager stood firm, took the fallout and accountability and refused to let that happen.

This manager knew what safe to fail was and stood up for it.

There have been many big stories lately of companies making gross errors, but organisations don’t have to hide behind them as savvy customers are more than willing to stay loyal to companies that stand tall and say ‘We are sorry, it was our fault.’

Atlassian had such an incident in April 2010 when a security breach exposed thousands of passwords. There were many responses to their openness, both positive and negative.

Zappos had a different kind of incident when in May 2010 they incorrectly priced their stock at one of their sister sites 6pm.com. They found the glitch a few hours later but to much surprise they honored the prices at a cost of 1.6 million (if you take their retail and not cost price). Word spread like wildfire and subsequent media resulted in a significant increase in their sales.

This week I found another major example crop up from one of my favourite pastimes – MMORPGs (Massive Multiplayer Online Role Playing Games).

 Trion recently released  a MMORPG called Rift that has been boasted as the potential  replacement to Blizzards successful World of Warcraft.

The release itself went quite flawlessly barring the fact that the game was so popular that the servers were flooded and queue times were staggeringly high. But the servers stayed up despite the load and the quality of the gameplay was high with very few bugs evident.

And then the security issues began. It started out fairly lightly as you would expect in retrospect, lurkers waiting for the players to actually accumulate virtual currency. There was a story or two of people having their accounts ‘hacked’ where someone else logged in as them and their virtual currency was re-directed elsewhere. Complaints on the forums resulted in attacks on those unfortunate enough to loose control of their account with citings of ‘poor security’ as the cause.

Within weeks it reached significant proportions. Although supposedly less than 1% of accounts were compromised it was rare to find a person who didn’t have a friend that has hacked. The forums became a mess of witch hunts. Players, sister fan sites, downloadable combat parsers, keyloggers and mostly the users were blamed as the cause.

On the 19th the Executive Producer of the game, Scott Hartsman, released a statement to say whilst some of the hacking was caused by traditional security holes such as keyloggers, and bad/re-used passwords from other games, there was indeed a defect that caused a man in the middle vulnerability that meant neither an account nor a password was required in order to hijack accounts. Kudos was even given to the user that found the breach. But importantly the breach was fixed within two hours (in MMORPG time this is like a heartbeat).

Replies from customers were almost unanimously positive with most boasting appreciation over the honesty that the company provided. My favourite reply was,

“I had cancelled my sub over this even though my account was never attacked, I cancelled out of fear I would be hit sooner or later. After this and the impressive response from the company I have since resubbed my account and will spend some time on my toons to enjoy the beautiful game that it is.”

by Mauvelence, demonstrating that being open and honest can lead to a more loyal customer base.

Will a security incident like this ever happen again in an MMORPG? Not likely –  all future companies will look at this and give it the focus and attention it truly did deserve prior to a product going live.

So what is safe to fail? It is having the guts to say you were wrong (though ironically only Atlassian said ‘We’re sorry!’). Safe to fail not only applies on a business to customer context but it also applies internally.

I would keenly love to know how the employee at Trion who caused the oversight in security was treated. Were they fired? Were they reprimanded? Or were they praised?

Human beings are completely imperfect. It is what makes each and every one of us so special. Creative human beings probably more so as creativity breeds innovation. So next time someone you know does something really wrong laugh it off with them and look for the positive learnings and results that have come out of it.

red tape
n
obstructive official routine or procedure; time-consuming bureaucracy

There are many corporate techniques out there that seek an approach to innovation by removing internal blockages and challenging existing paradigms.

In Agile this is no different. Techniques within Kanban deal with removing blockages by visualising the blockers and limiting work in progress to force a greater focus them. Challenging existing paradigms is also well understood as the term ‘sacred cow’.

So, how many organisations out there really and I mean *really* focus on removing blockages and seeking to destroy these sacred cows.

Other than putting it up on a board, what can be done to force a cultural change on removing blockages. Sure you can train people; have complicated registers for managing blockages across teams; an organisational social contract (value contract) regarding removing them but how do you get to the heart of the problem.

The essential issue is:

I (or my team) have a blocker. But the blockage is outside my direct area of influence. It is being caused by that person over there (points, but in reality that person might be five floors away). That person has lots of things on their plate. I sent them an email but they didn’t respond. I have no idea how important my blocker is to them.

Whose problem is it? Mine or theirs? You could escalate, but the management chain that they sit under is a path three points up and it seems silly to go that far up to fix it.

The obviously simplistic agile response is you would go directly to that person for a chat, explain your circumstance and get an understanding of when the problem might be resolved.

The likelihood of the problem being fixed is dependant on how easy it is to remove the blocker. A quick fix will probably result in an almost instantaneous actioning after the conversation. Once the difficulty of the blocker resolution escalates traction will be almost impossible; focus will be lost and communication regarding its status will become non existant.

So what do you do for the harder to fix blockers?

A truely Agile organisation would take a tough stance. I want to be in an organisation that takes such a tough stance.

My idea of the week?

Next time you have a blocker outside your area of influence cut a thick 1 meter long piece of red tape and put it directly across the door/cubicle entry point of the person that is blocking you. Write on the tape the blockage description and your name.

This takes balls. Leaving it up there when it hasn’t been fixed takes even more. I guarantee you – if your culture permits you to slap a big piece of red tape across a door then that the person that is being inconvenienced at entering their area will *really* take focus on that blocker. Even if the blocker can’t be fixed instananeously they will go the extra mile to ensure that it is resolved quickly and that the owner of the blockage is informed.

I would culturally take it a step further and say only the person that puts the tape up is allowed to take it down. That is real customer satisfaction. That is real “done”. Only the person that puts the tape up is allowed to accept a re-direct of the blocker to a new owner.

Don’t make an issue snake on their wall. An issue snake does nothing to cause inconvenience to the blockage point and doesn’t blaringly and embarrasingly shout out “I NEED FIXING!”.

Give it a try and post your results.

We’ve all seen it before. Agile projects that turn tragile, commonly without any one person’s fault and despite the best intentions of the team.

Projects which have no known velocity, no iteration kickoffs or showcases, little visibility of the plan and who is doing what and total uncertainty as to whether the business’s desired scope will be achieved by the release date, are more than just tragile – they are chaos in motion.

Imagine a chaotic project that is ¾ complete (or perceived to be) that you have been asked to fire fight. When faced with this type of project a purist Agile coach would (or could) be tempted to stop the line and force (or drag) the team back into adhering to normal Agile practices. An inexperienced coach would throw up their hands in terror and say ‘this isn’t Agile, don’t call it that’ and might walk away. A brave Agile coach will tackle the chaos in the manner they know best – with Agile itself.

When a chaotic project is ¾ complete there is a very strong push mentality of the team to get the project over the line. Any factors not directed at accomplishing the last 25% are ignored. This presents an Agile coach with an immediate risk and change threat. So how much change do you try to make so that the team is better enabled to deliver that 25%?

The following are some guidelines you might like to consider:

  1. The first step to fire fighting an Agile project that has turned into chaos in motion is to recognise all the failure points. Write them down as a coaching backlog of areas to course correct. Each story is a practice that the team needs to embrace further (or even begin doing).
  2. Size up the correction stories in complexity points – this needs to consider the cost to implement change as a coach and the cost to change as a team.
  3. Set the value that will be obtained by addressing the failure points. Keep in mind that you have 25% of the project to go!
  4. Set the priority of what needs to be fixed first based upon the value and complexity. This priority has to take into account externally influencing factors such as the planned release date and what can be accomplished in that duration vs. what needs to be addressed for the next release.
  5. Hold your own iteration kickoff walking the team through your approach to get buy-in, feedback and changes. Communicate frequently with progress so that the team cannot only see and feel how they are changing but also understand why they are changing.

As a high level approach it looks very simple. The difficulty is in knowing what are the right stories and how to approach them. Consider this chaos in motion – there is no known velocity, there are 80+ stories in some form of progress and there are four more weeks until the release date – How do you even know to what extent the scope will be delivered by the planned release date? How do you advise and plan for the future, especially if the current state is even unknown? This is uncontrolled chaos. You want to move this to controlled chaos by fundamentally breaking this down into stories that are achievable, for example:

1. Find out the current status of all stories. The team doesn’t have time to do this, the Iteration Manager / Scrum Master is in all likelihood now busy delivering and is no longer doing their iteration management function. An email won’t suffice as everyone is too busy to read emails. This is the uncomfortable bit since you have to get in everyone’s face and get the right status on everything. And it won’t be just once. You will find out what they are doing and then there will be a bucket load of stories which you have no idea what their status is. This will be a journey of discovery.

2.  Here comes the tricky bit. You won’t get an iteration velocity that is worth anything at this point in time, but you need to know whether you will meet the release date or to what extent you won’t. You will need to take a leap of faith that goes slightly against the norm of Agile iteration training. Ignore iteration velocity.  Forget it even existed. You will also need to ignore the complexity points of the stories that the team are trying to deliver. Forget that they exist too. This probably won’t be a huge leap for the team as it is highly likely that some stories don’t have complexity points due to the very fact that they are chaos in motion. From now on each story is worth a number of points based upon its current state in the flow. If the flow is:

backlog->analysis->build->system test->business test->completed

then allocate new points to the story based on its state as follows:

Backlog = 5
Analysis = 4
Build = 3
System Test = 2
Business Test = 1

Calculating the Total

Calculating the Total

Fundamentally this makes the assumption that all the stories are the same size and that each process step in the flow takes the same amount of time. We know this won’t be 100% correct but we are looking for an 80% fit here.

3. Add up the new values of all the stories. It might look like 273 points. Now on a daily basis track the number of transitions that all the stories make. Each single transition is worth a single point. If a story transitions more than one flow state in a day then count the multiple transitions e.g.  Analysis to Build and then from Build to System Test will be two points.

Calculating the Flow Movement

Calculating the Flow Movement

4. Establish your average velocity over a few days. It is now a simple mathematical equation of total points left divided by average daily velocity to establish your new release date (or confirm your existing one).

This gets you through the hardest problem. You can now provide the business with some clarity of delivery and the team now has a visible mechanism to track and celebrate progression. Now that you have an element of control in this chaos in motion you can continue down your backlog fixing further issues.