Welcome to day 3 of the 10-day playbook series for Product Owners in Sprint 0. Please read days 1 and 2 if you haven’t already (which focus on business problems, objectives, stakeholder identification and personas). Today, we will start drafting high-level future state models and eliciting the epics and features to form the top of our backlog.

Day 3

1. Draft straw man future state models (2 hours)

-Create a strawman high-level (L1) process flow, clearly calling out changes from the current state (if applicable). Remember: L1 process flows are meant to reflect the big picture view of your end-to-end process. There should be no decision boxes in this flow, and shouldn’t be more than 9 steps. Each one of these L1 steps will drill down into an L2 process flow. Steps within an L2 can drill down into L3 flows if needed. In the beginning, we want to paint the big picture of where we are going. Once we prioritize the features we are building, we can elaborate flows in priority order. You should really only spend about half an hour organizing your thoughts into a simple L1 flow. You can include KPIs that are relevant to your business objectives to outline improvements for specific steps here as well.

-Start to identify the business data objects (nouns) relevant to your initiative and form the basis of your Business Data Diagram. You may not know the relationships or cardinality for these objects just yet, but spend a few minutes in a brainstorm session putting boxes on the page for all of the objects that you care about. You will elaborate the BDD further through elicitation sessions, and having the objects on the page as queues can help structure the conversation. The BDD is very helpful for identifying underlying business rules.

-Identify the systems that impact (or will impact) your initiative and form the basis of your Ecosystem Map. You may need the help of a systems architect to validate which systems touch yours and how data passes between them, but spend a few minutes putting together a straw man with boxes representing systems you’ve heard or read about. Note: it tells a nice story if you can create a current state Ecosystem Map, then add a Future State overlay clearly calling out what’s going to change with color coding.

2. Validate high-level models and elicit high-level scope Items (4 hours)

-Using your org chart, identify the appropriate stakeholders and subject matter experts to review your draft models with. Remember, these are just straw man models meant to start the conversation about the scope to come. We are not looking for perfection or a complete detailed listing of our user’s needs at this point, but just enough information to validate our approach and get the top part of our hierarchy formed.

-As you discuss draft models, start to identify new features needed to support process changes, business rules that need to be considered, any new system integration modifications that are needed, etc. As you refine the visual model you’ll start to brainstorm the first set of textual requirements derived from model elements and your elicitation session results.

3. Draft high-level scope items (2 hours)

-The structure of your requirements hierarchy may change depending on the methodology you’re following (SAFe, SCRUM, or other). In SAFe, Portfolio and Program Epics sit above Features in the hierarchy. In SCRUM, Epics are simply large user stories that need to be broken down further (can’t fit within a single sprint); Scrum Epics sit below features in the requirements hierarchy. We like to forget about all of the jargon and just remember that our requirements objects are really just organizational units meant to categorize our needs at varying levels of detail. At this point, you should review your updated models and notes from elicitation sessions to start to group needs into L1 features (or epics). When identifying features, try to use a consistent naming convention. I prefer the active voice (verb + noun) construct when naming features, like “Reconcile Payout Variances” or “Compare Eligible Partners”.

-These features should be linked to the set of objectives you’ve defined in your Business Objectives Model. EVERYTHING that you identify for your backlog should tie back to the business value you’re trying to achieve. Spend some time reviewing your list of brainstormed features/epics and map them to objectives (which is much easier if you’re using a requirements management tool!). Immediately cut anything that doesn’t help meet the objectives you’ve agreed upon (but be willing to change your objectives if you uncover something better during the process!).

We will discuss methods for prioritizing your set of features on Day 4. Once the highest priority feature is known, you’ll start elaborating with drill downs of L2 and L3 process flows (plus other detailed models as needed) to get down to the user story level.