Hero #18
Posted on 8 January, 2019 by John Sicoli

Scope Creep in Agile Software Projects

At Intelligent Pathways we live and breathe software; from research to design, delivery to operations. It is a fun, busy, bumpy ride. In order to help iron out some of the bumps, we like to use the Agile software development methodology. One of my favourite phrases is “Change is the only constant” and as Agile embraces change, we too must embrace change. But, our clients often want software delivered on a fixed price and schedule.

How can you run a fixed software project while still embracing change?

This blog post is about finding a balance between your project scope and your project methodology and hopefully provides some insight to help manage scope creep.

Managing Scope in Software Development

What is scope creep?

Scope and scope creep really depends on the way you are running your projects.

Scope has a number of aspects including a set of features, assumptions about those features, and will include the resources and timeframe allocated to deliver them. When a deviation from one or more of these results in an increase in time, effort and/or cost, scope creep occurs.

As an end-to-end service provider, our projects can start with a statement of work indicating we will deliver a set of features based on high-level requirements. During delivery, we will refine requirements and build and test the solution. Delivery will also include a set of assumptions, risks and dependencies, and a fixed allocation of time and resources.

Starting with only high-level requirements means that we work closely with our clients to turn them into a solution. Clients rely on us to strike a balance between the best outcome with the allotted resource in an Agile fashion. But what does that really mean?

What is the Agile software delivery methodology?

In theory, Agile is intended to recognise the limits of planning in turbulent environments and to focus more on people and delivery than documentation and rigour.

But what does this mean in practice? Do clients really care about this?

In its simplest form, the most adopted part of Agile is to deliver small working components regularly. This allows clients to track progress and shape the outcome along the way. This is achieved via really short development cycles (2 or 3 weeks) called Sprints. During each Sprint designs are finalised and software is built and tested. If the client deems something is not suitable, they can request that the team iterate in the next Sprint, making any required changes.

This is fantastically flexible. In a pure Agile project, all stakeholders would be making all decisions together at the direction of the Product Owner until the finances are burned down to zero. This type of Agile is more common on well established long running projects.

For new projects, some flexibility is great but too much flexibility can have its drawbacks. Clients rely on us to ensure project funds do not become depleted before all features are delivered. Whatever aspects of Agile your project is going to incorporate, you will want to be sure to manage the expectation that all changes will have an impact. Agile roles such as Product Owner, Scrum Master or Iteration Manager can be responsible for monitoring, analysing and reporting on such impacts and should definitely be part of your way of working.

How your way of working impacts scope

Having a published, socialised project structure and a clearly defined Way of Working (WoW) are key elements that influence how scope is defined and scope creep will be managed.

Managing scope on a new lean green-field project can be a very different experience to a that of an established high-risk project that is simultaneously delivering new features and supporting production users.

For example, a new lean fixed project may only be focused on delivery and all sprints may already be planned for several months, whereas an established project may operate on time and material where the product owner sets the scope just before each sprint starts. Each of these will have a different method to request a change as well as a different impact.

If you are elaborating from high-level to low-level features where time or cost is fixed managing scope will be more about ensuring estimates remain within allocations so that a project can complete on time and budget. If your project is well established, the scope may only be fixed during a single sprint and the team may be more focused on taking the journey together.

Whatever WoW your project adopts, a conscious decision should be made taking into account the pros and cons of any particular approach. Some things to consider:

  • Project experience and complexity - How experienced are your team members with the methodology you will follow? Is your project just made up of one team or several streams of teams?
  • Project objective - What is your project objective? For example, do you have a cadence to ensure a new feature is delivered every three weeks or is it to spend the time to design the ultimate UX? Do you value hitting a set target in 3 months or flexibility along the way? Will you build an MVP first and iterate to improve it later?
  • Project role and responsibilities - What project roles will you have, who will fill them, and what will they be responsible for, what is their availability, experience, interest? What happens when a business need does not align with a technical limitation? Who monitors and reports on scope changes and estimations?
  • Project events and milestones - What milestones will your project have? Will you have design and planning workshops with subject matter experts (SMEs), estimation, sign-off, and demonstrations.
  • Project standards and methodology - Will your project adhere to a strict SDLC? Is everyone on board to follow a fixed process, or are you growing the process together? How does the client formally request a change in scope? Will you follow an existing style guide? Will test reporting and bugs be formal or informal?

As I mentioned above, change is the only constant and each of these factors will impact how easy it is to change and how big of an impact changes will have.

How to manage scope creep

Considering everything mentioned above, we typically find there are several phases where scope can be impacted. As I mentioned in a recent vlog on this topic, typical engagements have many touch points where the scope is refined from a high-level down to one or two specific solution options, these can include:

  • Tendering, EOI, and Statement of Work creation
  • High-level workshops with product owners and SMEs
  • Detailed designs and reviews
  • Backlog grooming and sprint planning
  • Development clarifications
  • Bug fixing and small enhancements

Features will be elaborated at each of these touch points and they may have several implementation options. The key to managing scope at these times is to foster high visibility through:

  • Tracking each feature against it’s allocated resources (time and/or cost)
  • Reporting on both project budget burndown and feature burndown rates
  • Clearly defining your roles and responsibilities and ensure role exists for a Product Owner, Scrum Master or Coordinator to actively perform monitoring and reporting
  • Ensuring estimates do not exceed those allocations
  • Ensuring the solution remains within any stated assumptions
  • Communicating the potential impact of any decisions made
  • Managing client expectations about your project methodology

If a solution is not going to fit within those parameters it may need to be reworked or you need to have a plan for change. Options can include:

  • Remove features - If one required feature consumes more allocated resources then an optional feature can be removed
  • Simplify the solution - If cost or time cannot change perhaps a similar outcome can be achieved with a simpler design
  • Change project scope - All projects should have a product/project management framework that has a clear process to allow the client to introduce a Change Request. Ideally, that framework will have resources available to perform an impact analysis of the request that does not impact regular project delivery.

In Conclusion

One of the most enjoyable parts of my job is to act as an early technical product owner on green-field projects, shaping many aspects of the team and product design. As things mature this role is typically handed over to a client business product owner.

One of the hardest parts of the job and perhaps life, in general, is coping with change. Hopefully, this blog post has given you some things to think about and will help you achieve successful outcomes on your projects.

By regularly monitoring and communicating your burndown rates you can avoid the 80/20 rule.

“The last 20% of the work takes 80% of the time” - Pareto Principle

Back to blog
John Sicoli
Consultant (Design & Analysis)

John is a Consultant with over 20 years’ experience in software design and analysis. John has worked on a number of enterprise projects in health, education, justice, and telecommunications. John is a passionate product owner specialising in user experience design, process improvement and business analysis. He has experience managing stakeholders and mentoring teams using the Agile software delivery methodology.