Craig Strong

I recently submitted another post to AgileScout.com, discussing the ever changing routes of project. There is still a natural habit for people to assume they can predict the future and plan projects in creative environments. Agile is about working with change and following value. If you are interested, pop over to AgileScout.com and have a read.

So you have a product backlog consisting of a nice list of user stories which have been loosely estimated by the team, and a team nearly ready to start ploughing through the exciting journey to building a product. You’re under pressure to get a deadline announced. What to do next?

Well at this point, I presume you don’t know the teams velocity as they haven’t started the project. Ideally the first thing to do (if possible) is to get one or two sprints done to get an idea of the teams velocity. You might be thinking that you know the teams velocity as they have just finished another project and it’s the same people. Don’t make the mistake of cross-applying the velocity to the new project. Each project presents different challenges and can be vastly different. If you presume to carry this over, I’m confident that you may be in for an unpleasant surprise!

After one or two sprints, you’ll have a rough starting figure from the velocity, or at the very least a list of problems which could drastically identify any fundamental issues missed during the product backlog derived from the retrospectives. Assuming you now have a velocity, you have your first step towards announcing a deadline.

Lets set the scene and say you have 1000 points in the product backlog and a cross functional team of 4 people to keep things simple. Your average velocity after the first two sprints is 100 points per sprint. Therefore you would be tempted to state the release backlog should be 10 sprints. At this point you might be thinking “Well I know that because we do retrospectives, and remove impediments, the team gets faster over time so I don’t need much of a contingency as the increased speed will give me some slack”. Don’t be tempted by this, it’s worth putting in a contingency as it protects yourself if your the PO and aligns business expectations. If you are ahead of schedule at the end, people are not generally going to be disappointed to hear you’re ahead of schedule or that you can develop more in the anticipated time frame.

Working out contingency can drastically vary between projects, companies, teams and environments. Depending on your knowledge and risk management strategy this can range from 5%-50%. A few things that I consider when calculating this, some of which have emerged from my own personal mistakes are :

1. Consider increasing contingency when working with smaller teams. In the example above with a small team of 4, it’s not unlikely that one or even two people could leave during the project. That’s at least 25%-50% of the workforce gone. If you have many teams totalling 100 people, it’s unlikely you’ll loose 25%-50% of the workforce at exactly the same time.
2. Consider the “Focus Factor” (A term I have borrowed from Henrik Kniberg : http://www.crisp.se/ScrumAndXpFromTheTrenches.html). Putting it simply, consider factors that could interrupt the teams concentration and commitment each sprint. The more of these, the lower the “Focus Factor”. The lower the focus factor, the lower the velocity and so forth. I suggest reading the above book for more depth on this topic.
3. Account for absences and holidays. Even if you are looking ahead for the next 8 months and nobody in the team has holidays booked, this is not to say they won’t appear later down the line. Failure to account for these could be detrimental.
4. Account for “White Noise”. The PO’s role is vital for the team to work in priority with enough detail and direction. If the PO is absent or distracted, there is a chance that the some focus will be lost for the up and coming user stories; similar to the “Focus Factor” mentioned above, but more related to the PO. This could be as a result of other business activity, sickness or general distraction from stakeholders.
5. Consider that the less you know, the greater the risk. When you have identified what you consider to be the likely risks, remember that contingency is to account for unknown risks. Always include a metric for completely unknowns which are not part of the above, those which could be categorised, but not detailed.

All of the above considered should present you the path to calculating a contingency. Don’t be alarmed to see high rates of contingency such as 25%-50%. It’s better to be truthful in the long term rather than tell people what they want to hear in the short term and fail. I sympathise that you can say next September and some people hear next June, but that’s their input not your output.

Another factor worth highlighting here is that contingency isn’t necessarily a buffer for additional work. This is the case with the fundamental Agile philosophy of welcoming change. Change should always be welcomed, but contingency is not part of a project to insert additional work. If we have 8 months to deliver a product backlog with 1000 points with a 25% contingency level, the contingency is there to deliver 1000 points, NOT 1250 points. Therefore the PO should note that if during the sprint review new requirements emerge, these should be estimated and prioritised, but not inserted into the product backlog without consideration to the existing commitment. The additional story should either replace an item of lesser priority within the backlog of the same estimated value or if all is required for the version release, the deadline should be extended to accommodate the additional work and the stakeholders informed. Being transparent about this often helps truly prioritise the change in its true scale. Failure to remember this, will put pressure on the team and increase the risk of failure.

Contingency is often within the projects to account for unforeseen circumstances which are not part of the original project plan. If you overestimate the consequence could be an early release or undertaking more features than agreed to in the same time frame which is often received well. Underestimating on the other hand, lowers moral in the team, invokes lack of trust and lets the stakeholders down which could be very costly for everyone. Build in and plan the contingency well into the release backlog and remember that saying yes in the short term to tell others what they want to hear is counterproductive and high risk for the PO.

When first introducing scrum into the workplace some time ago, many people had strong
views on what agility meant and certainly had some strong opinions on how Scrum should
be implemented. Some of these views created divides between teams, people and
processes. After quite some time re-factoring processes, communicating and refining
techniques everything started to take shape. We started getting to grips with TDD, had a
continuous integration server set-up, introduced product backlog tools to manage groomed producted backlogs and really
progressed well with the quality in writing user stories. In hindsight it was clear that what
we started with was far from what we needed and ended up with.

Although we seemed to follow the standard practice well and could see progress all
around, the first and largest project we started which was the project we introduced scrum
to the company with, was late and far from agile. Management had little confidence in the
project and were concerned that every time a change was made, bugs would surface into
the product backlog. Not only was the management concerned that change was
problematic, but confidence was so low that there was a fear that introducing new features
would put the launch of existing features at risk due to the possibility of new bugs
surfacing. This was not a good place to be for anyone!

Looking at this project many things went wrong, but most had been fixed. After a few root
cause analysis exercises we looked at the main symptoms. It was quite obvious the main
reason it was late was because the project developed an incredibly long tail of bug fixes.
“How could this be?” we asked ourselves, we have TDD in place, we have peer reviewing, a
pretty decent “done done” list and a few other XP practices in place. We knew bugs would
always surface as this is the nature of software, but this was a case where you fix one bug
and introduce three more. I began investigating the problem further, this was clearly not
the way to do it! I regained my title as Scrum Master in the problematic project and started to observe the team.

After a few hours I started to see the root cause of the problem. When the team were
tackling the user story they would notice bugs. However the bugs were “not directly
related” to the user story being worked on. As a result of this, the team would look down
the backlog and see a user story which covered the area where the bug surfaced. Then
they would negotiate with the product owner not to fix the bug in the existing user story, but
to leave it there and fix it when that user story surfaced. Apparently this would be quicker and it was a way to by pass the failing tests and negotiate a way around the “Done Done” list. After seeing this the penny truly dropped.

The problem with the above was that we were using an agile process with a waterfall
approach to the product backlog. After each retrospective taking this approach meant the
product was not shippable and the sprint reviews would introduce new directions for the
product. What this meant was that the user stories in the backlog which would fix the accepted bugs, may be removed, de-prioritised or never tackled. Therefore this meant that additional user stories had to be created to solve the debt which should never had been
there or that velocity would continuously decrease due to an ever increase bug debt.. The value of these user stories was very low. This exposed the fragility of the process and  also enforced why it is so important to ensure each user story is shippable by adhering the a clear, well defined “Done Done” list.

Following the identification of the above, we came up with a strategy to resolve the issue.
The Scrum Master (Myself), had to enforce a strong bug stance in accordance with a more
detailed “Done Done” list and flush the bugs out. Initially velocity went down considerably, but it was a
true velocity. After a few sprints not only would the bugs be flushed out, but the product backlog was much healthier. Managementʼs confidence started to rise again and although less was being delivered, what was delivered was shippable. After just a few sprints velocity started to rise and the long tail of bugs added to the product backlog started to diminish.

To conclude, we learnt at our expense that quality is a metric that is controlled by the team
and expected by the client. Putting off today what can be done tomorrow is not the path to
agility especially when this is quality. Doing so will increase the likelihood of project failure and make the product fragile.  The product backlog is a living entity subject to
constant change. Unlike waterfall the path is not linear and if it is, the path is not agile.

Image: renjith krishnan / FreeDigitalPhotos.net

For the past few months I have been involved with trying to refine some of the procedures in our Scrum teams. This is an on going process which always deems to be worthwhile. Obviously one of the natural activities which is the “retrospective” helps a great deal in identifying problems that need some attention which could be affecting production.

One of the most common conversations I hear with varying depth is where the team discusses issues (business functionality) that aren’t really problems, but they think are to some degree. They can spend valuable time worrying or debating such issues. What this is referring to is where the team will discuss items which they feel should exist, but do not. These are items the team didn’t commit to in the previous or current sprint, are not in the next sprint and in some cases not even in the whole product backlog. However the team feel that they should exist and question their existence, not bearing in mind that they might not exist for very good reason. The team should however be encouraged to ask the question, but also respect the answer if it validates its lack of existence.

Production teams are naturally innovative and if you have done a great job in setting these teams up, they will have a strong sense of ownership for the developing product and will want to add as much functionality as possible. Although these great ideas and high levels of enthusiasm are fantastic properties of the team, left uncontrolled they could cost the product a great deal and in some cases could cause a product to fail.

The Product Owner should really define and focus the “What” and “Why” in the product backlog. The team take these and decide on the “How”. This should not by any means create a sharp divide between the team, but an understanding of the product backlog priorities. A good Product Owner will often utilise the team to create “managed” innovative ideas which could add brilliant features to the product backlog with a large value to the end user. The Product Owner should communicate value to the team for each of the sprint goals.

Value isn’t measured by having the most features you can get in a short time, but by having a balanced product which is exactly what the user wants to satisfy their needs and goals. Therefore refining an already well used feature could add more value to a customer than by giving them a brand new “bells and whistles” feature instead of.

In short the Product Owner needs to take sole ownership of the product backlog. They should be communicating with the team as well as the stakeholders what features are being developed, when and why. The team can provide a great deal of input, and features can evolve from such input. However it’s the Product Owner who is the “ringable neck”; so getting a product in the right order and answering the “What” and the “Why” is explicitly in their interest. Production teams need to trust the Product Owner’s decisions and the Product Owner needs to work with the production teams to earn that trust. When that balance is found risk of change is reduced and production values can increase. Then the balance of responsibility for answering the “What”, “Why” and “How” is maintained.