Tag: planning

Tracking progress of the release

Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the release) or it’s not even desired. What happens in such cases is that delivery to the market is organised in some more or less formal releases that are shipped every couple of months (internal releases can be still more frequent, though). Working with releases doesn’t require almost any extra efforts, but still, it usually involves some additional activities like release planning and requires for tracking progress on a release level.

Tracking and adapting to changes on a release level becomes particularly critical if release goals are directly or indirectly bound to some marketing or sales activities that require some up-front planning and synchronisation. Fortunately, tracking release progress is not a rocket-science and most software tool that are available on the market support this functionality. JIRA, the tool that I’m familiar with, provides you with 2 simple reports that you can use at easy.

Version Report

Version Report shows your progress towards completion of a release (estimated work). It uses average velocity and estimated amount of work remaining to predict a forecasted release completion date (a date when all the estimated issues in the release are estimated to be completed). In addition, Version Report can be also used to monitor how a scope of the release has been changing since the start of the release which can be a useful tool for checking if release planning was valuable (great input for adaptation and team’s retrospectives).

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-version-report

Release Burndown

Release Burndown report shows how you’re burning story points of all the estimated stories that were planned for the release. It uses average velocity and estimated amount of work remaining to present a predicted number of sprints that are required to complete the release. Release Burndown report presents information on per sprint basis and therefore it can be used to track how much work was added, completed and left remaining in/after each sprint.

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-release-burndown

 

Splitting large features into smaller stories – Elephant Carpaccio

Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together.
It’s a common problem for many teams that are new to Agile, but my experience shows that it’s also a problem for more mature teams that prevents them from advancing to the next level of agility.
Why is that? IMHO it’s because many teams struggle with a concept of delivering software incrementally and they are much more focused on an iterative part of Agile paradigm. They struggle with understanding that larger features don’t have to be implemented in one chunk and that they can be built in several steps. It usually means that a given feature won’t be perfect from the very beginning, but it doesn’t have to be! It’s one of the key concepts of Agile – deliver value incrementally, wait for client’s feedback and adapt accordingly (if need be).
Many developers say that they can’t split a given feature into smaller chunks not because they are not capable of doing so, but because from their perspective something less than a whole feature is imperfect, non-functional and not worth presenting to any stakeholder.
It may be a huge problem because it influences planning and tracking & monitoring, and therefore impacts transparency and works counter short feedback loops. Improving it requires changing the mindset and adjusting way of thinking which is never an easy process.
The good news is that teams are not doomed to fail here. First, they learn how to split larger features into smaller chunks as they progress with Agile and gain more experience. In addition, Agile itself forces them to do so because there is nothing more embarrassing than holding a sprint review and having to explain to stakeholders that there is nothing to present and discuss.
In addition, it’s possible to encourage the right approach by doing some exercises with the teams. One of them is called “Elephant Carpaccio” which I hope you’ll find useful. It was originally proposed by Alistair Cockburn and you can find more details about it here.
I executed this exercise with my teams and I must say that the results are quite promising. Of course, there were a lot of discussions and complaining, but overall people liked the idea and said they learnt something from doing it. Pretty much everyone agrees it was a challenge to split an application they would deliver in 1 hr into 20 small user stories, each of them of a meaningful value to a client.
If your teams struggle with splitting large features into smaller stories I recommend doing this exercise with them. It’s bit “artificial” but should result in some fun and good discussions afterwards.

Inter-team Commitment Stories

Managing complex and lengthy projects is a challenge. When dozens of people are working on the same product in parallel there has to be a mechanism for identifying and resolving dependencies and cross-team blockers.

In traditional projects, it’s a PM’s task to ensure that all the team members are working on right tasks in right order. She is the one who decides about priorities, monitors progress and initiates corrective actions when required.

In the Agile world, there are self-organising teams that are accountable for delivering outcomes they committed to. There is nobody who defines how the work should be done or what actions need to be taken. Of course, there is a Product Owner who sets priorities, but there is no direct mechanism for synchronising work between various teams.

There are several frameworks (i.e. Scaled Agile Framework or Nexus Framework) for scaling Scrum that provide some solutions for managing complex product development efforts, but still it’s up to the teams how they self-organise around managing project dependencies.

A solution that can help resolve a problem of managing dependencies in complex Agile projects is a mechanism called Inter-team Commitment Story (please refer to Agile Project Management by Jim Highsmith).

Inter-team Commitment Story (ICS) is a form of a story that works as an agreement between two or more teams. It’s a kind of a contract that defines set of responsibilities on each party’s part and specifies what and by when should be delivered to get the dependency resolved.

ICS may be somehow overseen by an integration team or project leader (they can be the ones to identify the dependencies in the first place), but it’s teams’ responsibility to mutually agree how a given dependency will be handled. Of course, it’s also Product Owner’s responsibility to make sure that Inter-team Commitment Stories are prioritised accordingly and that a pressure to deliver business stories doesn’t make some teams blocked.

Inter-team Commitment Stories are planned and scheduled as all other stories in the product backlog. And most of all, ICSs are estimated so that the cost of managing team-to-team coordination is not hidden. The main advantages of this mechanism are:

  • dependency management and coordination work are visible,
  • it downgrades the coordination from project manager to teams that know the details,
  • it helps to build accountability,
  • it supports inter-team collaboration and builds cross-team relationships.

 

Estimating software projects

Couple weeks ago I came across a great article about software estimation by Pawel Brodzinski which made me think about how my approach to estimating software projects has evolved over time.

At the moment I work in product development where Agile approach is used to deliver new increments of software. We have stable teams and we use Story Points and Velocity to estimate and plan our sprints and releases. But I used to work in project-based companies where a reliable process for estimating projects was a key factor for our long-term success. It wasn’t important only from project perspective, but the estimates were used to forecast our revenue, they influenced recruitment, resorucing plans, etc. They had to be more or less right.

Estimating software projects is difficult, error-prone and time-consuming. Of course, one may say that Agile approach is a good solution to this problem, but unfortunately not all the clients are willing to follow it. In your response to many RFPs you’re obliged to provide 2 numbers (I call them “RFP twins”) – cost and delivery date – before you even have a real chance to talk the client.

My personal experience confirms that spending more and more time on estimating doesn’t improve the quality of an output you get. It’s even more misleading because adding more details to the scope definition doesn’t make the final estimates better, but it makes you biased by feeling more certain about what you have just come up with.

Years ago I thought that giving lot of time to senior developers to analyse the scope, break it down into tasks and estimate them, would give us an accurate project schedule and minimise a risk of failure. Project life showed, however, that it didn’t work as expected and that our estimates were usually wrong regardless of how much time we invested in getting them.

Over time my approach to estimating software projects has changed and I started using a different process for getting estimates. The first step is to define a team that is going to work on the project (something like 1 full-time visual designer, 2 developers and QA specialist, etc.) and then involve experts (that team, preferrably) to say how many days/weeks/months (units depend on an overall project size) that project is going to take. The scope is no longer split into fine-grained tasks, but it’s rather broken down into a couple of a high-level modules/functionalities/deliverables. The whole process is time-boxed to prevent digging into too many details and to minimise the effort that is invested.

The second step is to compare the results with projects of a similar type and size that were done in the past. I don’t have a precise definition of what “similar type and size” means, but the teams usually don’t find it difficult (it can be a project that a similar team worked on or a project with similar functionalities, etc.). This approach is far less “scientific” than the one described by Pawel in his article, but the goal and reasoning remain the same – to use historical data to verify the estimates and to avoid being biased.

Finally, the estimates should be provided as ranges (like “this project/functionality requires 2-4 weeks of a given team effort”) – bearing in mind the huge uncertainty creative software projects are faced with you should be aiming for a right order of magnitude rather than a precise number you’re never going to meet.

Last but not least, all the assumtions that were made during the process should be documented and stored along with the estimates. I even suggest that a thorough, generic list of assumtions is built over time so that it can be used as a checklist and therefore save time and make you not forget about “something obvious”. Moreover, assumptions usually enable you to come up with some changes to project scope that can be presented to the client and that could lower the costs of the whole endavour. From my experience I can say that such suggestions are usually a good starting point for more detailed discussions with the client (especially when the client was initially reluctant to do so) and makes it easier to convince the client to have some workshops with you before final cost/schedule commitments are done.

 

To summarise, I recommend using the following ideas when estimating software projects:

  • use historical and empirical data as much as possible to avoid biases
  • if only possible, organise workshops with the client to get a better understanding of the client’s needs
  • combine different approaches (i.e. statistical forecasting + sanity check by experts)
  • don’t spend too much time on estimating – it won’t improve your numbers after all
  • provide estimates in ranges (the project will take from n to m days/weeks/months)
  • invest in accuracy, not precision
  • document your assumtions

 

 

100% utilisation myth and slack time

In my recent blog post I covered a topic of limiting Work in Progress. I briefly mentioned that in many companies working on many tasks in parallel is somehow more important than accomplishing them.

100 utilisation myth

Many organisation believe that their employees should always be busy with work which results in aiming for their constant 100% utilisation.

At first glance it may sound reasonable – after all, we’re getting paid for having hands full of work, aren’t we?

Well, I think that employees are not paid for being 100% utilised, but for getting things done. In my opinion, getting software out of the door is far more important than working hard on dozens of tasks in parallel for a sake of being busy.

But it means that smart organisations should optimise their processes for effective deliveries, not for keeping everyone busy. It’s counterintuitive, but allowing for some slack time gives better results than aiming for 100% utilisation of the staff.

Why is that?

  • Multitasking

While working on a task you always get somehow blocked at some point of time (i.e. waiting for somebody’s feedback, facing a blocker, etc.) and therefore to stay fully utilised you need to switch to a different project. You multitask. You handle many things in parallel.

  • Context switching

Multikasking reduces quality and productivity because it involves a lot of context switching. Humans don’t actually multitask at all – we fast-switch. And switching between tasks requires context change and it takes time we need to get at full speed back again.

  • Time to market

Decreased productivity means than less things (if any!) get accomplished in the same period of time. High utilization inevitably creates queues of projects. Delivery dates slip and time to market increases.

  • No time for innovation or improvement

Planning for 100% utilisation creates a terrible environment for work, an environment of no innovation. Innovation requires creative workers to have time to observe and think. But it can’t be planned or scheduled. Innovation usually emerges as a result of slack time which doesn’t exist in organisations striving for 100% utilisation.

  • Projects get longer to complete

When a partially completed tasks sit idle, waiting for capacity to become available, the overall duration of the project grows. 100% utilisation also means that there is no time to handle urgent, unexpected issues and therefore even more planning effort is required to squeeze them in.

  • Delayed feedback

Increased time to market delays feedback, causing developers to follow unproductive paths longer. Delays make it hard for companies to adjust to evolving market needs and to detect weaknesses in their product before it’s too late.

Again, it’s counterintuitive, but you will deliver your projects cheaper and faster if you allow for a fair amount of slack time.

Slack time

There is no precise definition of a slack time, but it basically happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work (i.e. developer cannot code or QA cannot test).

Slack time usually results in working on improvements of any kind or, in good, self-organising teams, advancing the current flow by helping resolve the bottleneck (i.e. developer picking up QA tasks).

What is the right balance?

While striving for 100% utilisation is harmful, it doesn’t mean that having as low utilisation as possible is the right approach either.

Optimal utilisation should be a balance between a cost of delay (which grows exponentially when utilisation becomes too high) and cost of idle resources (which usually declines linearly when resource get more and more utilised). There is no one-size-fits-all solution, because it very depends on the organisation, nature of the project, etc., but in many cases, however, a sensible utilisation target is around 80%.

Last but not least, it’s very important to note how utilisation is calculated. Nowadays, corporate stuff (meetings, reports, emails, etc.) can consume lot of time and therefore it automatically decreases utilisation. Please bear in mind, however, that 80% utilisation target refers to time left for project work, not overall employee’s capacity. Of course, every organisation may approach this problem in different ways, but in the end “corporate burden” can’t be excluded from the equation.

 

Relative Value Points

Product backlog should be DEEP – detailed appropriately, emergent, estimated and prioritised. Everyone who learns about Scrum should be familiar with these key attributes of a good product backlog.

But how is the product backlog ordered? Well, most Scrum practitioners would probably say that it’s Product Owner’s decision, but the business value seems like a fair attribute to be used for product backlog prioritisation.

While saying so is a good generalisation the reality is, unfortunately, a bit more complex. The reason for this is that a good product backlog consists not only of client-facing stories, but there are also other items like design spikes, technical debt reduction stories, maintenance items, etc. Smart Product Owner knows that she can’t concentrate on business stories only because she’s responsible for long-term product’s adaptability and reliability.

In addition, things like upcoming marketing event may also drive prioritisation and, therefore, short-term value and features of a lower overall value can take precedence over long-term gains.

Furthermore, risk mitigation is also a very important factor that influences how product backlog is ordered. Actual risk reduction is a key objective that the team should concentrate on at the beginning of a complex project. For example, it makes sense to prioritise some technical stories first to check if a technology we want to use is right the project before investing too much money into an endeavour that may eventually fail.

As you can see ordering a product backlog is an act of balancing many different factors, and although business value should be the main driver other aspects also influence decisions made by a Product Owner. It’s worth remembering that there is a difference between value and priority.

OK, but how does a Product Owner know a business value of all the stories? Of course, it’s a Product Owner’s job to understand what set of features the product needs to have to delight its users, but how does a Product Owner make day-to-day decisions when a product backlog consist of hundreds or thousands of items? Relative Value Points (see Agile Project Management by Jim Highsmith) and ROI is the answer.

Value points are somehow similar to story points, but they are calculated top-down instead of bottom-up. The idea is that value points (i.e. 1, 2, 3, 5, 8 and 13) are assigned to features first, and then a percentage of total feature points is calculated for each feature (i.e. three features with 3, 5 and 8 value points assigned get 19%, 31%, and 50% respectively). Next value points are allocated to stories (the same way), but the percentages assigned to a set of stories are capped by the percentage of their parent feature (i.e. if the first feature consists of two stories with 2 and 8 value points assigned, the percentage for these stories is 4% and 15% respectively).

As a result of using this simple algorithm all the stories in a product backlog have a percentage value assigned. A value of each story is relative to other stories and, therefore, allows for comparing them with regards to a business value they deliver to clients. Relative value points can be further used to allocate revenue stream or net present value (NPV) to features/stories, but most organisations don’t go through this step (many organisations don’t do a good cost-benefit analysis at all).

Value points have another advantage – they increase transparency and understanding in the team. They can be also used to calculate a relative ROI (Return On Investment) for each story which is another tool that can help the team make better decisions regarding priority of backlog items. In this scenario, relative ROI can be defined as a ratio between the business value of a story (in value points) and its complexity (in story points). Please bear in mind that relative ROI can’t be converted to money, but allows for comparing user stories – a chart below can help Product Owner see which stories have best ROI:

relative value points