Ok, now we have a project goal and a list of wished initial requirements and the team has been informed about them. The next thing to do is to divide the project into a series of sub-projects each one of them should produce a measurable outcome.
Why to split the project into smaller pieces?
This is an agile practice taking its roots from earlier ideas, like the Boehm’s Spiral methodology or Gilb’s Evolutionary one and is done to minimize risks of producing nothing at all or what it was not asked for / expected.
You can see more about these benefits in my older post about iterative development.
We have created a vision but who ensures us that it will not change during the project lifetime and will stay with us? We have an initial idea / concept – maybe even validated by an initial feasibility study – but who will ensures us that it will remain valid until the end? What if we have two or three good ideas and want to see which one will survive the live tests, not only on paper?
What if the project will be cancelled halfway through? Did we do half-good work for nothing? Are there no intermediate re-usable outcomes?
We continuously need to revisit the vision and ensure that we are on the right track.
We need to accept that the world is uncertain and that we often have no clue—but we still need to find ways to go forward. Because we are uncertain, we cannot trust a specification but must have the living customer perspective around. Because we are uncertain, we will make many errors and must learn to kill off some deliveries early. Because we are uncertain, we need everyone’s input and perspectives, which makes teamwork and creative brainstorming key ingredients. And so on.
Of course, it might be that the project is simple or that you are pretty sure the vision will not change, you will not need to pivot or there will not be new business / technology opportunities; in this case you don’t need to use iterations.
How to make the iterations: scope
Ok, so we said that the idea is to take the project goal and split it into a series of sub-projects, each one with a milestone and an associated outcome. Every sub-project is therefore a project in itself, with a planning at the beginning ant the committed scope to achieve something tangible at the end, and they will be executed one after the other, in a row.
This means that you have to select a portion of the backlog and commit to deliver it in the coming iteration. It makes absolute sense if you select the first portion of the backlog: the one with the highest priority tasks or with the greatest risks or bringing the most business values. In this way you will minimize failure risks and delays.
This portion of the release backlog becomes the iteration backlog, that can be further refined.
Every iteration has its own overall goal or theme (enabled by delivering the iteration backlog). After every iteration, the team delivers a potentially shippable result, which can be put into production, should the product owner so wish (maybe it was a prototype to verify an assumption or maybe the results are not satisfactory).
Please note the importance of having a fully potentially shippable product at the end of each iteration, this is pivotal in ensuring that you can stop or pause the project anytime and still have something produced.
Therefore, everything that needs to be done is done, including testing, analysis, purchasing, preparing for installation, process descriptions, and whatever else is needed to fully deliver the iteration theme.
An important practice from Agile (specifically from Scrum) says that the iterations shall be fixed in length and this is actually a good idea.
Why this? The reason behind it is to have the team (that shouldn’t change between one iteration and the other, it’s a fixed team) gaining a rhythm, a sort of trained way to do, as you know it’s the practice that makes the person the master.
If they are sometimes two weeks and sometimes four weeks then this natural rhythm is never established. Iterations then begin to feel like arbitrary units of time with endpoints selected more by outside forces (perhaps political or competitive) rather than designed to enhance the overall productivity of the team. When the duration is allowed to vary teams have a harder time selecting the right amount of work for the sprint backlog, which may result in less commitment to completing all of the items in the iteration.
But by keeping the same length this becomes like a corporate heartbeat which everyone comfortably settles into. There is no argument about release dates and such because everyone knows that every – say – 4 weeks there is a release, period.
How long could be each iteration?
This depends a lot on the kind of projects, it’s not unusual to have iterations (called sprints in scrum) 3-4 weeks in length but if you don’t have a long testing or deployment phase then you could reduce the sprints even to one week; on the other side if you have longer production or planning phases, you could dilate the sprints to a longer period, maybe even 2-3 months.
The rule of thumb is: longer the iteration, less agile is the team to react to changes and customer feedbacks. With shorter iterations you also minimize the risk of running in the wrong direction, you can learn and improve faster. On the other side, longer iterations are good for the team because they get more time to recover from problems and still make the iteration goal. It’s a balance between speed and adding overhead (deliver, put into production, testing, planning meetings, demos, etc.). So, try to keep the iteration as short as possible whilst delivering meaningful products.
For example, you can start with an initial length of a classic four weeks and then for the next project reduce it (more likely) or increment it, according to the results.
Having agreed on a sprint backlog, the team must now understand what each item really means, and each item is broken down further. Yes, the items in the product/release backlog are high level, remember? And now it’s the time to detail them. You don’t want to lose time too early: what if a backlog item is at the end not realized or removed entirely from the backlog? Therefore you break them down only when you are sure that they will be done in the next iteration.
Refine them means for example to define the acceptance criteria (by product owner) or to split the user stories into tasks (you should keep each one of these broken-down tasks less than one day, never bring one of them to the next day; the goal is that every day the team members have something completed).
My suggestion is not to update the Excel-based product backlog with respect to the task breakdowns, and rather use a separate iteration backlog – based on any tool – for two reasons:
- The task breakdown is usually quite volatile, i.e. they are frequently changed and refined during the sprint, so it is too much of a hassle to keep the product backlog synchronized.
- The product owner doesn’t need to be involved at this level of detail anyway.
You could use a separate Excel file or even better a whiteboard / wall with post-it notes. The simpler, the better.
This post is part of the series “Z2A: From zero to agile”.