Requirements and Product BacklogThe product backlog in a fixed price engagement is your scope of work and in Agile Scrum, this is your master list of requirements to be prioritised. What this means is that for fixed price, all items in the product backlog need to be completed by the end of the project. This is in contrast to a scrum backlog, where the highest priority tasks are “picked” at the start of each sprint. Therefore, all components of the development lifecycle are captured here in the form of tasks (or stories if applicable) from requirements, analysis and design, to build, test and deploy. This is your work break down structure and your map to follow for the project.
In Agile Scrum, Product Owners have the opportunity to revisit the product backlog anytime and reprioritise the tasks that they want the team to tackle in the next sprint. So why not in a fixed price project? The only difference is if new items are brought in to the backlog and prioritised or removed, this equates to a change in scope and the relevant change control processes would be engaged i.e. change request and subsequent agreed re-scoping. This shouldn’t be seen in a negative light, but as an essential step in ensuring customer requirements are met.
Planning and EstimationIn Agile Scrum projects, sprint planning is where the team would come together and decide as a team, what is achievable for the duration of the sprint, with a sense of priority and guidance from the product owner. The team picks tasks from the top of the product backlog and estimate the effort required to complete it.
In a fixed price project however, the sprint goals are predetermined, the backlog priorities are already set, and the tasks to be completed are already estimated to be feasible for the sprint duration. So why hold a sprint plan? The simple answer is to create the opportunity to challenge the timeline, the work being performed and the outcomes the sprint is looking to achieve. Are the goals we set 2 months ago for this sprint still relevant? Are there more pressing items to address? It is better to answer these questions intermittently than at the end!
Showcases and RetrospectivesShowcases enable the team to demonstrate the capability that has been delivered in the sprint. This does not need to change in a fixed price project. The team can organise showcases so that whatever part of the project they are working on can be demonstrated to stakeholders. It is better to get feedback (good or bad) early so you know what works and what needs to be addressed.
This is where retrospectives in Agile makes the process of continual improvement within the team much more achievable. It is important for the team to reflect on what went well and what could have been done better. Holding these sessions is just as important in a fixed price engagement. If the processes or products being developed are found to be not working, it provides the opportunity once more for change control processes to kick-in and allow the team to continue down the right path.
At the end of the day, it's about expectations that are agreed upon and being able to manage this as flexibly as possible when something does come up (and it will!). Having a framework to help keep everyone (delivery team, project manager, customers/stakeholders) on board and aligned makes for much happier outcome.