Day 72 — Creative PM series 6/7: “Scope Management”

Roger Tsai & Design
Daily Agile UX
Published in
6 min readMay 11, 2019
Original Photo by Dallas Reedy on Unsplash

As notorious as it is, one of the many pains project team often suffer is “Scope Creep”. Without carefully managing the scope, it’s easy to allow unimportant feature requests piling up and create a giant monster in your product backlog. How do we ensure we spend time on core features of MVP instead of letting low-value features distract us? In today’s article, I want to share what I learned in Scope Management, in the following structure:

  • Value of Scope Management
  • When to Manage Scope
  • Typical Challenges
  • How to Manage Scope Effectively

Value of Scope Management

Project Iron Triangle. Image source:Harpreet Dhillon
  1. Strategically utilize resource: As the project iron triangle dictates (figure above), in order to achieve great quality, we’ll always try to balance the three points in the project triangle. If the timeline & budget (resource) are fixed, then bigger the scope, the worse the quality. Therefore carefully managing the scope is an important aspect to ensure quality delivery
  2. Align strategic goal: The Scope of Work document (SoW) is supposed to reflect what’s the strategic goal we’re trying to achieve. For example, if the project goal is to improve user experience of an existing platform, but there’s little amount of work planned for design and front end development, then we might need to take a close look to see it the SoW is really aligned with the strategic goal.
  3. Create release strategy and dissect into meaningful release: Another important aspect is to have a clear release strategy, and review and revise the scope to fit in with the strategy. What is important to verify in MVP? What features and wait till the 2nd release? The release strategy should be the guideline to determine the scope of work.
  4. Manage expectation from stakeholders and team: The SoW is also a good tool to communicate and manage expectations with the business team and stakeholders. Without SoW, merely using mission and vision statement is hard to draw a picture of what actually needs to be done.
SoW is an important tool to clearly define project goal and what needs to be done. Photo by Annie Spratt on Unsplash

When to Manage Scope

As you probably know that, scope management starts from the beginning of the projects — the planning phase, but it doesn’t end there. It should be a continuous work throughout the project lifecycle, with certain specific timing that requires more Scope Management:

  1. When receiving important feedback/ request: Whenever there’s some important feedback/request, whether it’s from an angel investor, CEO, or user testing, it worth spending time to analyze if the feedback/ request will pivot the product direction hence have impact on the existing scope.
  2. Sprint planning and Sprint review, Retrospective: After a Sprint review or Retrospective, the team should learn the WWW: what-went-well and what-went-wrong. Some of the insights might change the way we work, and address the missing part of the work or redundancy. Therefore we might need to address these changes in our project scope
  3. Major product release: Usually what we know as “moment of truth”. Through the product release, we might find bugs, issues, user feedback, and all sorts of factors we need to adjust for the next release. This is a good time to review the general scope to see if we need to pivot to new direction.
  4. Financial/seasonal planning: Depending on the project funding, our release plan might change accordingly. Therefore, this is also a good to to review the scope and see how it fits in the grand strategy.
Project funding can be another source of scope change. Photo by Jp Valery on Unsplash

Typical challenges

Stakeholders feedback

In my past articles, I talked about a typical challenge of scope management: Stakeholder relationship. A lot of times the scope change comes from stakeholder’s feedback, and whether the team agree with it or not, they have to be addressed it in some way. Whether the belongs to front burner, back burner, or kitchen sink, carefully documented these feedback is helpful so that if the market/ technology condition changes, we can quickly review and reshuffle these request to best suit project needs.

Time & Resource Constraints

“Fast, cheap, good, pick any two.” With the feature requests coming in, we need to reflect on the scope of work. And to ensure the expanding scope can be well taken care of, we need to ask for more time and more resource (more designer/developers). However, it’s not always easy to get more resource or adjust timeline, but the new requests from stakeholders usually don’t wait for us to be ready for it.

Scope Creep

Along the similar line as the point above, without carefully manage the incoming product request, the scope of work can easily become scope creep, and the product team get distracted by working on low-value feature request.

“Fast, cheap, good, pick any two.” Image source: Misfit’s Architecture

How to Manage Scope Effectively

Start with clear vision

Whenever there’s a new request comes in, we have to ask our stakeholders and ourselves, how does it align with our mission/ vision statement? If we cannot see the clear alignment, then we might have to ask what the business/user value is from this request. Is is merely someone’s shower room inspiration? Do we really need to address this type of request?

Always align with user’s benefit

Even if the request might have potential business value, how much user value does it create? Or is it actually hurting user experience? For example, we often heard from stakeholders that we need to put all sorts of marketing content in our product/ service, we know from Hicks’ Law that makes it hard for user to quickly get to their desired destination with all the distraction. Therefore, we should be mindful when handling this types of request, and counter with research and usability testing results.

Use prioritization tool

When we receive a feature request that’s reasonable and add values to both business and target users, then the question is when and how to add it into the backlog and release plan. There are many types of prioritization tools, for example, 1) MosCoW, 2) Value vs. Complexity, and 3) KANO model. These tools help us understand what types of value a feature could bring, and we can therefore determine if it should be in MVP scope, or later release.

Have a good-idea box

Whether the feature request is feasible for the MVP or not, we shouldn’t just disregard it. Having a “good-idea box,”, “back burner”, or “icebox” helps us document these ideas for later use.

Kano model is an effective method to help prioritize features. Image source: WLP

Additional Resource

Conclusion

  1. A good scope management not only ensures quality product, but also builds good relationship with stakeholders with good expectation management;
  2. Scope management is a continuous work throughout the project lifecycle, especially when there’s major release or receiving important product feedback;
  3. To avoid scope creep, always align the feature set with user and business values, and carefully prioritize the feature into product roadmap.

What are some methods you use for scope management?I’m eager to learn from you.

ABC. Always be clappin’.

To see more

All Daily Agile UX tips

The opinions expressed in this article are those of the author. They do not represent current or previous client or employer views.

--

--