Deriving Scope from Purpose

Defining scope is hard. There are lots of unknowns and strong opinions. Features pile on like linemen after a fumble and you’re trapped under the crushing weight of an immense, incoherent project. Purpose is your referee. It can peel off player after player until the project can go forward.

Why minimize scope

Why bring in the referee, though? Why do the hard work of defining scope? Why not just pile on all the features and make everyone happy? Minimizing scope means you:

• ship sooner, so people can start benefiting from your work
• decrease errors at launch by having less surface area that can break
• decrease wasted time and effort building features based on guesswork instead of feedback
• prioritize the most impactful work by launching and prioritizing subsequent features against all the team’s work instead of holding the launch hostage for low impact features

How to minimize scope

Purpose is a powerful tool you can wield to send features slithering back to the holes they crawled out of. I prefer to write theory and abstractions, but as a reader that usually bores me, so I will try to keep this concrete.

The project

Shopify is fully remote, but provides locations around the world for teams to collaborate in person. We were using a third party application to do this, but it required a lot of manual work to keep the program running, including copy pasting data out of the app. Our renewal was coming up. There was no way to automate retrieving data from the app and there were no better apps we could use instead, so we decided to build something bespoke for our unconventional use case.

Defining the purpose

The purpose of this project is to build an app for booking on site time that does not require manual work. That’s what my initial thought was, but it’s wrong. The purpose of this project is to replace our current booking solution before the contract renewal with a better path towards automation.

Identifying the purpose can be hard. Asking, “what does success look like?” can be helpful. Frequently you will get feature based responses. It needs to do x, y, or z. Do not accept these. Keep asking questions until you understand the underlying problem.

If the goal is a silver bullet solution, lots of purposes wrapped up in one project, identify the primary one. Keep the others in mind, so your solution can grow into them in the future, but they are out of scope.

Results Parity

For the initial launch all we need is feature parity with the current solution:

• Users inputs desired dates
• It displays all the available rooms and their details, like capacity and photos
• Users book a room

That’s not true, though. All we need is results parity:

• A room is booked

Results parity is similar to feature parity, but it strips out the how. Our current solution was a generic room booking tool. It is not optimized for our use case. At our locations all the rooms are all similar and designed to have everything necessary, so the specific room does not matter. The location is more important because it determines how far everyone will have to travel.

The better feature to build is a way for users to see all the locations with availability for their group size and select the one they want. The end result is the same, a room is booked, but the features enabling it are different.

This means that we don’t need to build a way for admins to upload and store pictures of rooms, or pages where users can view these details. It also means users don’t have to dig through all the available rooms looking for the location they want with the capacity they need. By focusing on results parity we were able to simplify the build and user experience.

Evaluating features

Google Calendar integration

The current app does not integrate with Google Calendar, it’s a manual process. This means we don’t have to build the integration, we could keep it a manual process. However, we need to do inventory management to ensure we aren’t double booking rooms. We could build our own bespoke inventory management in our app, or we could just use Google Calendar’s and have added benefit of knocking out this feature. Build!

Meals

Our locations provide breakfast and lunch, however, we don’t know which meals people will be eating there making it hard to plan. The feature request is a way for attendees to specify which meals they will be eating when they RSVP. This is not part of the current solution, we can launch without it. Backlog!

Pre Approval

Events are approved by the head of the department, but some teams have created processes outside of the current app to enable a review process before submitting to the department head. This is something that we should likely bring into the app because it is part of the process multiple teams are creating in bespoke ways, but it is not necessary for launch. Backlog!

Lock in Scope

It is common for new ideas and feature requests to pop up throughout a project. Constantly having to address these and determine whether they are in scope is distracting. It also moves the goal posts on your build and can impact timelines and therefore trust in the project.

Define the scope at the beginning of the project, get stakeholder sign off on it and then default to no on anything that comes up afterwards. Simple process diagrams and design mock ups can be helpful to ensure stakeholders have a good understanding of scope when they are signing off.

How did it turn out?

We kicked off the project in January and had a deadline of May when the contract for our existing solution expired. We launched very smoothly at the beginning of April with only a couple bugs with low user impact. We discovered that the highest priority next features were around reporting, not anything on our backlog that we could have built preemptively. We still have not built the meals, pre approval, or most of the other backlog features. Work on products other than this app have been determined to be higher priorities.