The Complete Guide on Project Scope

The Project Scope defines the deliverables, deadline, and may include an estimated budget. It is a document, sometimes called a Statement of Work (SoW) that encompasses what both parties have agreed will be built. It should state both what exactly is being delivered and what is considered out of scope. Out-of-scope features could be items that the client knows they want eventually, but won't be included in this build. It is challenging, but taking the time to make one properly will vastly improve your chances of delivering a project of high quality, on time, on budget, and that meets your client's needs. As such, your scope definition should be complete and explicit.

Defining project scope gets everyone on the same page: the stakeholders, the vendors, the product owner, the project manager, and the engineering team. It helps to manage stakeholder expectations. It should be easy to refer back to in order to ensure you are on track. It is also essential to understand the business need for the project. It is important to understand where, how, and who will be using the software once it's done. If you can meet the users in person and ask them about it, all the better!

Some questions to ask yourself as you create your Project Scope:

• What will be achieved by this project?
• Who has the final say? Who is the product owner?
• What are the deliverables?
• What is the timeline, in milestones?
• How much will it cost? What is the payment plan?
• What should not be included?

How to Scope a Project

1. Define your deliverables
This usually happens in multiple conversations with your client. As you work to get more specific and come to understand their desired outcome, you will begin to fill in the picture. It is important to keep in mind that there are: known knows, known unknowns, and unknown unknowns. The less that is unknown in a project, the more accurate the project scope, timeline, and budget will be.

2. Acceptance Criteria and Exclusion
As you create the list of deliverables that will be included, it will also be important to keep a list of those items which are discussed but which are also determined not to be a part of the scope. In addition, it is essential to identify what are the conditions and performance requirements for the scope.

3. Create a timeline with milestones
Estimating the time of a project is difficult. Senior engineers will be much better at this simply because experience is the best teacher in this case. Consulting with someone who has built many projects and has written a lot of code will help you approach accuracy. By identifying discrete user stories, which should represent small individual components of a project, it becomes easier to estimate. Throughout the years, we have found that nothing takes less than half a day. If your engineer is coming back with 1 or 2 hour estimations on user stories, it is likely that they are thinking in terms of, "How long would it take me to write this code in ideal circumstances?" They are not thinking about distractions, research, or unpredictable issues. They are not thinking about the time it takes to test, qa, or deploy. A senior engineer will be more able to take a comprehensive view of what it takes to bring a feature to full completion, even understanding the time involved after a developer hands it off to QA or DevOps. Then, you will need to coordinate individual user stories into a complete unit of deliverable features called a milestone. At Bixly, the smaller the milestone, the easier it is to be agile. Therefore we prefer to do milestones in coordination with our two-week sprints, rarely exceeding 2 sprints per milestone.

One thing to keep in mind is scope creep. Scope creep occurs when project deliverables exceed what was originally agreed upon in the project scope. There may be very legitimate reasons to add to the feature list. However, there should be a known process, such as a change order, for doing so. This allows both parties to agree to whatever the new timeline, price, and scope will be taking into consideration new features and deliverables. Feature creep isn't just about throwing off your timeline and budget. It's also about understanding the opportunity cost of delaying the release. Depending on your market, you may need to weigh more heavily the consequences of losing time to your competitors.