Welcome to day 2 of the 10-day playbook series for Product Owners in Sprint 0! If you are just getting started and have NOT read part 1, go back and read the introduction and day 1 playbook before reading any further.

Day 2
1. Continue with non-facilitated elicitation as needed (2 hours)

• Continue with document and interface analysis
• Consider the creation of questionnaires/surveys if you want to get baseline data from a wide audience quickly
• After you’ve read existing documentation and conducted interface analysis, you can ask to observe some users executing their day-to-day processes

2. Identify the Business Problem (2 hours)

• By this point, your project should be funded and you should have access to the business case that won the investment dollars to move forward with your initiative. Often, these business cases contain very high-level problem statements. As the Product Owner, it’s your job to drill down into these pain points to understand what the real requirements are. As you go through the process, make sure you stay aligned to the high-level outcomes the project investment was intended for. Those outcomes should just get broken down into smaller parts with associated problem statements that help you understand why you aren’t able to achieve your business goals today.
• Remember that business problems typically fall in one of three categories: something that’s costing too much, something that’s preventing revenue growth/not making as much money as it should (could be a missed opportunity), or something around business risk (risk of business loss – like customers going to the competition, OR risk from regulatory findings)
• To start to break high-level problems down, create straw man process flows for the current state, then validate and discuss your flows with stakeholders. Call out pain points specifically with color coding and notes and baseline KPIs outlining more detailed problems.

3. Define SMART Business Objectives (4 hours)

• Remember your SMART acronym when setting business goals – Specific, Measurable, Attainable, Relevant, Timely
• Working from the high-level outcomes defined in your business case and the more detailed problems you identified from current processes, start to draft a business objectives model (see our ArgonDigital Business Objectives Model cheat sheet here!). If you already have a list of features in mind for your solution, you can include them here, but we will focus more on features in future days during sprint 0. Try to avoid the fallacy where you are working backwards to define objectives for solutions that have already been decided upon. First identify what problems you want to solve, define what it looks like when those problems are solved, and then work with your IT partners and delivery team to determine the overall best solution.
• When defining objectives, use the format: “Increase/decrease/enable [some thing] from [baseline] to [target] by [specific timeframe]”
• Start to validate your objectives with stakeholders and business sponsors. One of the most difficult parts about this piece is setting SPECIFIC goals, which means having a clear baseline with a clear target defined. If you find you are NOT able to obtain actual data, use whatever data is available, document your assumptions, and take your best educated guesses. Your objectives can be revisited and updated as you get more data available and start to validate/disprove your assumptions. Assign owners to objectives so someone is responsible for tracking and updating assumptions, and measuring the achievement of those objectives (even long after you release software!)
• Be wary of the fallacy where your problem is a lack of a solution, and your objective is a solution (e.g. business problem: this process isn’t automated so it takes too long; business objective: automate the process). You should be thinking about the REAL problems and objectives that relate to money. In this example, your problem should be: this process takes too long, which costs the organization an extra $X per year. The objective would be something like: reduce the cost of this process from $X to $Y by reducing the time it takes to execute the process accurately.

You might be thinking, wow this is a lot of stuff to get done in just two days! We are by no means saying these models or activities will be COMPLETE during this period. The idea is to be lean in your process and identify just enough from each step to move forward, knowing you’ll be elaborating on your deliverables through an iterative process over the coming weeks and months as you start to execute on real sprints. In agile, we want to identify our highest priority feature as quickly as possible so we can identify and elaborate stories for just that feature (enough to get started), then we move on to the next. We also want to embrace empiricism, which is we learn much more through experience than we will know at the very beginning. By stepping through this sequence of activities quickly we embrace the idea of change, knowing you’re going to learn tomorrow and even more the next day, so why spend too much time making anything perfect right out of the gate? We want to avoid analysis paralysis where we are spending too much time on any one activity. This slows us down, and it is not necessary. In agile, we value working software over comprehensive documentation. These methods help you to ensure your documentation is adequate to get the outcomes you want, but not so extensive that they prevent the team from moving quickly through new scope items.
Stay tuned for day 3 where we start to identify and organize epics and features.