Defining scope is an iterative, interactive process. As you go through it, you'll find elements of your scope expanding, shrinking or changing shape in response to feedback from analyzing and planning out the work.
Note: It's a good idea to get the feature definition process under way before setting up planning folders (see Create a planning folder), because defining features gives you the raw material for your planning process.
Before you get started, you'll do some kind of user research, even if it's only
a few phone calls, to get an idea of the needs of the customers you hope to
satisfy. Express these needs and desires as stories about what a user can do
with your product. Then create an artifact for each user story you identify.
A user story describes the situation after your product has been launched:
What can the user do now that they couldn't do before? Tip: For best results, your user story artifact should by limited to a clear description of the capability you want in the product. Remember that a user story is not an implementation plan. Details about the implementation will be recorded in the user story artifact, but when you write a user story, try to leave the implementation up to the developer who will be responsible for it.
- You may want to define one or more fictional users who resemble the real-life users of your product. This can help simplify and focus your thinking.
- Use the Priority field to express your opinion of how important the story is to the user. In general, the most eagerly desired capabilities will be addressed first. (During implementation planning, your Priority setting will be used as one input in summing up the effort involved in each priority level.)
- Make it as clear as you can at the outset what degree of functionality is acceptable. For example, if your team is creating an airplane, how high must it be able to fly? How far must it go before refueling? How many passengers must it carry? Stating your acceptance criteria concretely helps reduce the time needed for ongoing reviews and changes.
Note: This is just a basic outline of what's involved in defining the scope of a product. If you're new to agile practices, you may enjoy Michael James' video collection.