Introduction
This week we introduce the basic elements that are needed to conduct a project using the agile methodology. Most agile projects will incorporate versions of the elements that are presented here.
Practical guidelines, examples and templates are provided, where possible, to provide you with the capability of using these in your own projects. It is important to remember that agile incorporates technical and social aspects and while there are descriptions here of the tools and their operation, the agile project leader will apply these tools using agile management techniques, such as servant leadership and effective communications.
The Agile Project Process
The agile project process that is discussed here is mainly based on Scrum – the most popular of the agile approaches. It begins with reflection and review of activity in the previous period, draws work for the current iteration from the overview of the project (the product backlog), develops the details of this and implements it in a collaborative way. Other forms of agile, such as Kanban, may do this on a continuing basis without iterations but will adhere to the principles discussed here – refinement of work as the project proceeds, regular production of completed work and a collaborative approach to team activity.
Retrospectives
Agile methodologies formally include reflection on and continuous improvement of the project activity. At the end of each iteration, or at the end of a period of project activity, the team reflects on the effectiveness of their work and determines improvements that might make it more effective in the future.
This review of activity is known as a retrospective and its outcome is considered at the start of the next period of activity. It is therefore appropriate to consider the retrospective as the starting point for the agile project process. The team takes its list of possible improvements from the its previous work on the project and identifies the improvements in their activity which will feature in the next period. They will not necessarily try to complete all the activities that have been identified, rather, they will focus on the most important activities that can reasonably be accommodated in the work of the team.
At the end of the next period of work, which may be an iteration, sprint or may be after a period of time or activity has passed in the project, the process will be repeated. Retrospectives will be completed regularly in an agile project.
A retrospective should be very simple and will usually focus on three questions:
- What went well in the previous period?
- What improvements could be made based on the previous period?
- What should be improved in the next period?
The leader of the retrospective meeting should try to ensure that it discusses both positive and negative aspects of the previous period, beginning with the listing of positive aspects. They should try to stop participants quickly moving to consider solutions and instead ensure that they carefully reflect on any problems that they identify, possibly by using common problem solving tools such as Fishbone Diagrams or the Five Whys. Take breaks to allow people to refresh and reflect and encourage participation. At the end of the retrospective there should be a short discussion on the effectiveness of the retrospective itself.
The Product Roadmap
The work that the agile team will do is often based on a Product Roadmap. It is often thought that agile projects do not have an overall plan for their work but that is incorrect. Rather, the product owner will often create a Product Roadmap that will show the order and timing of the major project deliverables.
There are various forms that the Product Roadmap might take. These can be goal oriented, and so include the project timeline and the goals and features of those goals that will be achieved in each time period. For example, here is a possible Product Roadmap a Fast Food Burger Restaurant order system automation:
| Date | February 15th | March 15th | May 15th | July 15th |
| Name | Phase 1 | Phase 2 | Phase 3 | Phase 4 |
| Goal | Layout plan | Layout modifications | System installed | System operational |
| Features | -Incorporates staff and user opinions
-Is easy to use for restaurant staff -Minimises restaurant congestion |
-Minimises restaurant disruption
-Quality consistent with restaurant standards |
-Rapid, easy order placement
-Supports rapid order fulfilment Operates reliably |
-Restaurant staff are comfortable using the system
-Restaurant operating costs are reduced -Restaurant staff are trained in system daily maintenance |
| Metrics | -Consultation meetings held with all staff
-All staff have positively evaluated prototype
|
-Restaurant operates at 95% of normal volume during construction
-Construction quality evaluated by professional and assessed as consistent |
-Under 2% user abandons
-Order average placement time 60 seconds -System operational 99.5% of restaurant opening hours |
-Staff satisfaction survey results are good
-Restaurant operating costs reduced by 20% -All staff pass training completion assessment |
Within each time period there may be one or more iterations to achieve the goals that have been set.
Other forms that the Product Roadmap can take include the Now-Next-Later model which creates focus current work:
The Storymap is another form of Roadmap that focusses on idea development. In this case the focus is on the user’s desired attributes of the product:
There are other forms that the Product Roadmap can take that may be useful, depending on the nature of the project and organisation. Their purpose is that an overview of the main elements that the project will work on are identified.
Product Backlog Preparation
At the beginning of the project, the work that will be done is listed in order of priority. This is known as the Product Backlog. This doesn’t need to be all of the work that the project will do, just what will be worked on in the first iteration and the one that will follow it. The Product Roadmap provides the overview of the whole project and later project activity can be detailed in the Backlog when it is needed.
Items in the Backlog provide information on what the project should do. They can be expressed in many ways, the most common of which is User Stories. These are statements that describe who the work will benefit, what it is and how it will benefit them. It often uses the format, As (describing who), I want (describing what is desired and so that, describing the benefit that it will provide to the user. For example:
“As a customer, I want a cancel button in the automated ordering system so that my order can be easily revised if I make a mistake.”
Or
“As a staff member, I want the system to provide guidance on food preparation so that I can be confident the food is being prepared correctly.”
The Backlog can take many forms – we will focus on the one that is used in Scrum which is based on user stories, which is the most widely used in the agile approach. The creation of the backlog is led by the Product Owner who is responsible for ensuring that the project meets the requirements of the user or client. It is detailed for the near-term activity and broader for activity which will not be completed until further in the future. As the project proceeds and these more broadly described stories will soon be worked on, they are detailed further.
The backlog should be easy to change. As the project proceeds requirements may change, based on changing resources, preferences of clients and users, past experience within the project etc. Items should be able to be modified, added or removed from the backlog to accommodate these changes.
There are two backlogs in an agile project. The Product Backlog lists all project activities that are currently known, in priority order. The Sprint Backlog, lists the items that are intended to be completed in the current project iteration and is also listed in priority order. Here are examples of both:
The Product Backlog is created by the product owner and should reflect the desires of the client or user. Modification of the Product backlog should be the responsibility of the product owner, who will consult with the client, user, project team and other stakeholders. A simple model for the Product backlog is:
| Order | Item | Status | Estimate |
| 1 | As a contractor I want the area where the modifications will be made to be cleared so that my work can start smoothly. | 3 | |
| 2 | As a customer I want a clear process for buying food during the modifications so that I can get my food quickly. | 3 | |
| 3 | As a staff member I want the modifications to be dust free so that they won’t impact food preparation. | 5 | |
| 4 | As a manager I want the new ordering machines to be installed near the door to the car park. | 8 |
The Product Backlog table includes the order that the items will be tackled, the items themselves, their status and the Estimate. The Estimate expresses the relative effort needed for each item. It is used to enable a Sprint Backlog to be prepared with a manageable workload.
The Sprint Backlog contains the work that is being done in the current iteration of the project. It is created by deciding on the goals for the Sprint and then selecting the User Stories on the Product Backlog that should be addressed to achieve the objective.
These User Stories are then used to create a list of tasks that will be necessary to achieve them. The hours needed for each task are determined to ensure that all of the tasks can be completed during the Sprint – if there are too many hours it may be necessary to modify the goals and remove stories from the Sprint and either address them in a future Sprint or remove them from the project.
Backlog Refinement
Planning in an agile project is undertaken as the project proceeds. We have seen that the Product Roadmap provides an overview of what the project will do and that the detail of the work that will be done is defined as the time to complete the work approaches. In the Sprint, user stories from the Product Backlog provide the basis for the tasks that will be completed.
The Product Backlog user stories are refined (Backlog Refinement) during the previous increment to the increment that will complete them (in the Agile Kanban model they would be done when the team focusses on the next story). The team considers the user stories from the backlog and may develop, led by the product owner, their understanding of the product requirements, including the creation of new user stories that expand their understanding. Limitations on the time used for this activity are common so that the team doesn’t spend too much time on planning. It is typical for no more than one hour per week to be used for Backlog Refinement.
Daily Standups
Daily Standups enable the agile team to coordinate their work with each other. It is a time limited meeting – usually no more than 15 minutes – in which members of the team report on the work they are doing by answering 3 questions:
- What did I complete since the last standup?
- What am I planning to complete between now and the next standup?
- What are my impediments (or risks or problems?
It can be facilitated by any team member and will usually take place while the team is standing in front of the project Task Board. Other agile models may use different standup formats but are based on the same principle of having a daily focus for team collaboration. In projects where the team is distributed an online format can be used.
It is important that the meetings are not simply providing updates on the work of the individual team member activity but that they also enable collaboration to take place where members provide advice and support to each other.
Demonstrations / Reviews
Regular demonstration and review of the work that the team has been doing are central to the agile methodology. Completing project elements enables the product owner to discuss them with project stakeholders and provide the team with feedback that they can use in ensuring that the project best meets its objectives.
These demonstrations should take place frequently. Two weekly intervals for demonstration are usually suggested but this will depend on the needs of the project and can be more frequent or less.
Planning for Iteration-Based Agile
The work that is done in each project iteration should be based on the capacity of the project team. This will depend on many factors, including the capabilities of the team members, whether people need time away from the team or need time to understand the work that they will do. The agile process is intended to ensure that the work that is committed to for each iteration is aligned with the team capacity, understanding that events that are beyond the control of the team may prevent this.
Execution Practices
eXtreme programming, a form of Agile, provides tools that are intended to enable the project to be completed rapidly and at an appropriate level of quality:
Continuous integration: As parts of the project are completed, combine them together to see that they work together as is intended.
Test at all levels: Regularly test individual project elements and the whole.
Acceptance Test-Driven Development: The project team creates criteria for its products and tests that will be conducted to see whether these are met, which are then used as the team creates the product.
Spikes: Research experiments that allow the team to gain knowledge that will help them in the project.
Conclusion
The iterative agile process creates regular delivery of project elements, where possible completed products. The practices that are described here are commonly used to enable this to happen. They begin with the results of the work in the previous iteration. The demonstration of the work from the previous iteration is reviewed in the retrospective and the team pulls the work for the next iteration from the product backlog. It then refines that into the work tasks that will be completed in the sprint and uses a task board to manage its activity. Daily scrums support the collaborative nature of the agile methodology.
Project Leadership 