Agile backlog optimisation – how to get the maximum from your agile sprint.
For every orginisation who uses agile methodology for it’s development environment, the effective planning of an agile sprint and it’s corresponding backlog, is the very basis on which a successful agile development project is built.
A well planned and well executed sprint that will deliver on it’s objective, is very much dependant on having an effective strategy for building a backlog that will support the sprint and virtually ensure the anticipated results.
In this article we will look into the process of how to define the sprint’s objectives, build a supportive backlog and then manage the sprint along it’s life cycle of 2-4 weeks, using the backlog as a roadmap to sprint accomplishment.
Step 1 – Having a clear view of project’s objectives
In non-agile (waterfall) environment projects or organisations, it’s very common to find the client/stakeholder’s business requirements laid out in a requirement document, later on developed into technical requirements. But in an agile-based project the tendency in most organisations will be to create user stories that will describe the desired outcomes from the system being developed.
In some organisations you could find a hybrid of the two, but in this article, we will focus on the user story-based approach. This approach ties in very well with the agile approach because the user story describes a system feature that the user will be able to use once it is developed. So basically, the agile team develops a system feature, described via a user story, during the sprint, as we will discuss below.
If you haven’t yet encountered user stories, it is essentially a way to describe a desired feature of the system, in enough detail so that the development team can assess the amount of time needed to develop that feature.
A common way of defining user story is in the following format:
As a <role> I can <capability>, so that <receive benefit>
For example: as the CFO of the company, I can create a report of all monthly expenses sorted by expense code and sum, so that I can compare them to last month and see the trends.
So, considering the above example, it is just one of many user stories that will be composing the collection of features and, in turn, abilities, the system will grant to it’s users.
It is usually the product owner’s responsibly to make sure that a collection of user stories is written for the product, so that the development team will have the development subjects well defined, and ready to be fitted into sprints.
It is also highly important to create acceptance criteria for each user story. With the acceptance criteria, it’s possible to make sure the desired feature was indeed met with the development that was performed by the team.
After having developed a considerable amount of user stories it is time for sprint planning.
Step 2 – Sprint(s) planning and optimisation
So we now have a collection of user stories that describes what we need from the system. This can be a “from scratch” system or a system that has been around for some time that we want to add more features to.
The next step is to just place every user story into a 2-4 week sprint and get going, right?
Wrong.
In fact, this is a sure-fire way to waste resources, have feature colliding, not finish on time and more problems.
What needs to be done now (and often isn’t done properly), is to plan and optimise the sprints. And this can be done with the following steps:
- Developers will assess the development time needed to develop and deliver each of the user stories presents to the team. It’s also a good idea to have testing time estimates for each feature delivered at this stage.
- After getting a rough idea of the development time needed, we can start thinking about placing the user stories into the sprints. We need to be planning out the content of following sprints (3-6 months worth of sprints, or even 1 year’s worth). To get properly optimised sprints content, what needs to be taken into account now is:
- What are the priorities set out by the organisation? Are there features that are needed sooner or are more essential? If there are, prioritise these first.
- Are there dependencies between the features described in the stories? If so, the sprint content should reflect that.
- Are there elements that will be developed for one feature that can be used for another feature? If possible, the element should be developed first and used again in the other feature. This situation is common for those who develop services that can be used (called) in different features. This is also common in developing of test procedures.
- Complexity of development and potential problems. If these can be anticipated, taking them into account can be very useful.
- User stories that are too big to fit into one sprint will be divided between two sprints.
- After all user stories have been assigned to sprints, the team should develop the backlog for each sprint. This is essentially a list of tasks with the person responsible and the status (percentage completed).
- Now, here is an additional optimisation step most planners never do – after completing the backlog for each sprint, have a second look at the sprints content. You may find additional opportunities here to further optimise your sprints! For example, you may find that developing a certain element will be much more beneficial to do in the first sprint and not the 9th sprint, because it can save a lot of time and effort from the beginning. Another think to look at are possible duplications in tasks, that can easily repeated without re-inventing them.
Step 3 – Progress and monitor
Having a good basis for the sprints is very much dependant on good sprint planning, having an effective backlog in place for each sprint, and tracking the team’s progress. Scrum meeting are usually held daily to track the progress of the team, and take care of problems and delays as soon as the appear. An important factor here is to stay connected to the client and make sure that every changer or new requirement is translated to the sprints. This will almost always prevent misunderstandings between the development team and the end client.
Process Diagram:
