How to Use Scrum for Fixed Scope (or Deadline) Projects

Hey folks! Today I just want to give you some feedback based on my personal experience about how to handle fixed scope projects by using Scrum.

We all know to do scrum in a fixed scope (meaning fixed price and deadline) environment is somewhat tricky. However, it is still usual in many software projects, fixed scope is just simply the norm especially for the big organizations who are in the early stages of their Agile transition. 

I do not want to go into details about the benefits which Scrum offers us but might be good just to list a few of them below to keep in mind:

·      High visibility of progress and regular feedback from the internal customers.

·      Predictable rhythm and measurable productivity (via burndown charts, team velocity, etc.).

·      Low bureaucratic overhead (meetings, documentation, etc.) and emphasis on face-to-face communication.

·      Easier adaptability for changes as the problems are identified earlier etc.

So how should we get the same benefits even though working in a fixed scope project. Here are some advices to achieve this:

1.   Try to work with a dedicated team: Senior and motivated people will definitely help your organization to work in that tricky environment but more important aspect of the team should be that the colleagues have to be dedicated to this one single fixed scope project to avoid context switching between multiple projects. 

2.   Find a product owner who already has experience about Scrum: Product owner is typically a project's key stakeholder as he/she should has the vision of what he/she wishes to build, and transfer that vision to the scrum team. If you are working with an Agile experienced one, the stakeholder community will be represented with a ‘single voice’ thus removing any chance of unclear points between the business and the scrum team.

3.   Start with "Sprint 0": Always start with a preparation sprint (also known as the “sprint 0”) before the complete team started working on the first “real” sprint. The expected output from this sprint should be creation of source code repositories, ready staging environments, ready tools for issue tracking, scrum boards, etc. Also the first user stories should be defined together and be ready to develop.

4.   Create a product backlog by using the fixed scope requirements: The goal here is not to try to specify each user story (the list of the fixed scope req.) in details for the whole project (this would be both time consuming and unnecessary because requirements will change in time anyway) but to give the team a way to roughly estimate the user stories and features. There are several methods to estimate user stories like "poker planning" or "story points" and you can select one of them based on your organization's culture.

5.   Use Burndown Charts: As you can see below the graph shows two main things: On the x axis you can see the plotted the sprints available for the release. On the y axis the number of story points to implement the functionality for that release. Based on the process in every individual sprint we will have the chance to keep track of the overall progress and the fixed scope project’s deadline.

6.   Avoid over commitment: Before understanding the actual team velocity, we should definitely avoid over commitment to the stakeholders and try to keep both sprints and releases realistic. We can always add some extra work if the goal of the sprint is reached later on.

7.   Motivate your team by celebrating sprints: When the team finishes the sprint, it’s important to celebrate this together with the “shippable product’s” demo. It can be simple and you can select how you want to do this based on company’s culture. But anyway it will surely motivate the team to reach the next deadline and as always make the collaboration even stronger.

8.   Handle change requests by swapping them: Let’s be honest even in “fixed projects” we all know that requirements will change in time, they always do, and no one can prevent this as this is the nature of product development process especially for the software world. So what we can do is instead of trying to prevent CRs and have a lot of internal fights, just swap them! This can only be achieved by working with the product owners. So during our project as the product owner receives new insights and discovers functionality that is redundant, we should offer the product owner the opportunity to swap some of these already changed user stories with the ones which are in similar size (based on story points estimations by the team).

I know it is not easy to follow these steps as it is written in the book but if your team members really believe in the power of agile methodologies, and you have a great team with a solid product owner, it can work. At the end of the day as Thomas Edison quoted: “Our great weakness lies in giving up. The most certain way to succeed is always to try just one more time.”

Hope this article will give you some practical insights about how you should use Scrum as a weapon to work with fixed scope projects.

Please feel free to comment and/or drop me a message in case you need to discuss more.