How to better understand and manage Scope

How to better understand and manage scope?

As I explained in one of my previous blogs, every project has a definite scope, budget, and a start and end date, which in the project management World are referred to as “Triple Constraint” i.e. you cannot change one without changing other two.  

Scope defines:  What work will be done?

Time goals dictate: How long should it take to deliver?

Cost goals impose: What should it cost?

As a project manager, you must balance these three often-competing goals.

In my 30 years of experience and running multiple projects of varying sizes and complexity, one common factor was my ability to understand requirements and break them into manageable increments so we can get working products in the hands of the users as early as possible. The objective is to get first-hand feedback from users and adjust the prioritization of features accordingly. 

In the Scrum framework, the scope is delivered using an incremental and iterative approach. We break requirements into features, called epics, which we intend to deliver in a Product Increment (PI). A typical PI is between 12-16 weeks. And Product Increments (PI) are delivered using 2 or 3-week iterations, called sprints. 

As I stated earlier, the scope is managed by breaking it into epics, and epics are further divided into user stories. The rule of thumb is that epic must be sized such that it can be completed in a single PI and a user story must be sized so it can be completed in a single sprint. 

Who is responsible for writing the user story?

In my experience, the Product Owner (PO) must be responsible and accountable for writing user stories. On large projects, PO may delegate this responsibility to one or more Business Analysts (BA) who translate PO’s vision into user stories. However, this does not transfer PO’s accountability.  

Best practices to follow when writing a user-story

A user story must be written clearly and unambiguous. It must describe “who, what, and why,” but not the “how.” The purpose is to empower the development team to find the best solution.

You must ensure that the user story:

• Is easy to understand.
• Explain the sub-feature (activity and the expected result) from the end-user perspective, e.g., “As a [type of user] I want [some feature] so that [some reason].“
• Has indisputable Acceptance Criteria (AC). 

Why is clear “Acceptance Criteria” critical?

The acceptance criteria define the boundary and the expected outcome. It helps the development team to design and build, the QA team to validate and test, and the PO to accept and close the user story. Good acceptance criteria must document both the positive as well as the negative scenarios.

User-story Lifecycle

Though the nomenclature may vary, more or less the below table lists major stages of a user story life cycle. 

Stages	Purpose	Accountability
Grooming	Document functional including: ·       Business Rules/Scenarios Mapping ·       Process Flows/Logic Maps ·       Wireframes (UI/UX) ·       Exceptions.	Product Owner
Technical Elaboration	·       Create technical design ·       identify the relationships between stories, i.e. predecessor stories are completed ·       Lastly, ensure the story meets the “Definition of Ready.”	Technical Lead
Estimate Size	·       Assess effort required and assign story points	Development Team
Commit to a sprint	·       PO will prioritize user stories by assessing their impact and the value they create for the business.	Product Owner
Complete development	·       Actual build.	Development Team
Quality Test	·       Create test cases ·       Prepare test data ·       Execute test cases.	QA Team
Demo	·       Review the functionality with users	Development Team
Approve and Close	·       Test and validate that it meets the listed ACs	Product Owner

Conclusion

Following are some of the best practices that I’ve used to manage project scope and achieve project goals:

• Keep the scope realistic. If a project is very large then divide it into a series of small increments.
• Engage end-users in scope definition and management by making them the PO, i.e., assigning ownership of specific features.
• Whenever possible, use off-the-shelf hardware and software.
• Use agile methodologies such as prototyping and building on top of the previous build per iteration.

Successful project management means meeting all three goals (scope, time, and cost) – and satisfying the project’s sponsor!