As teams transition to agile, getting into a structured cadence of story ideation and elaboration is critical. Product Owners and analysts need to get in the “sweet spot” of having just enough documentation just in time – you don’t want to get too far ahead because you’re spinning your wheels on analysis for things that are likely to change and won’t be built for too far in the future. You don’t want to get behind because that means your team’s velocity can suffer. We promote for Product Owners to stay around two sprints ahead with a sprint-ready backlog. This ensures there is enough buffer in the backlog to keep the development team productive, even if blockers arise requiring shifts in work prioritization.

As teams are getting off the ground, it’s important to have a Sprint 0 cycle where the team can level set on the new methodology, come to terms with team definitions (Definition of Done, Definition of Ready), get aligned on initiative objectives, and have time to get the all-important sprint-ready backlog in place before jumping into development. During this time, your scrum team should be working in parallel ensuring all scrum team members have been identified, environments are set up, necessary research spikes are complete, team definitions are agreed upon, etc. This checklist is meant to focus on the activities of the Product Owner and Business Analyst during this period. Sprint 0 can last anywhere from 1-6 weeks, depending on the team’s maturity, agile experience, project complexity, time to set up tools, etc.

This series will present a day-by-day playbook for Sprint 0 activities over a two-week period. Each post will include a breakdown of analysis activities for a single day, with suggested times for how long to spend on each activity. These are by no means hard and fast rules for how to complete Sprint 0, but should serve as helpful guidelines for the activities that can add value to scrum teams embarking on new initiatives!

Day 1
1. Obtain organizational chart (or create one) and identify all relevant stakeholders (2 hours)

• Your organization SHOULD have one of these already. If you don’t have a copy or aren’t sure if it exists, talk with someone in HR about creating one for the company.
• If one does NOT exist, use the active directory to start to find everyone’s full names, job titles, managers and direct reports. You don’t need to map out the entire organization, but ensure all of your stakeholders are included, and keep going upwards in the hierarchy until you reach a C-level executive. This can help with forming relationships and understanding what political environments might exist around your area.
• The value of this is making sure you aren’t MISSING anyone on your elicitation plan. If you fail to talk to key stakeholders, you will definitely miss requirements!
• Create sub-mappings outlining the scrum team, specific sets of Subject Matter Experts, those involved in UAT (plus other overlays that might be helpful, like the steering committee) as necessary (I call these “team maps” or “SME Maps”. This is completely optional but can prove to be very helpful to keep track of lots of important names when working on a large project. I like to create a map of the scrum team with roles color coded, so when we get on the standup, I can follow along as each team member contributes with their updates, or I can have a checklist for meeting invites to ensure I’ve included anyone then color code when people attend or not.

2. Identify User Personas (2 hours)

• Think about various market segments and ANY people that have a stake in your product, then start to group them with other people of like interests/needs
• Create a Personas Diagram to understand responsibilities, interests, success criteria, concerns and constraints for each persona
• Identify subject matter experts to elicit/validate requirements for each persona

3. Create an elicitation and stakeholder management plan for the upcoming weeks. (2 hours)

• Don’t spend too much time planning, but identify what deliverables you need to produce and who needs to review them, which SMEs you need to talk to for which features, and get your sessions scheduled on the calendar. See our ArgonDigital Tools for Requirements Gathering Sessions here to get prepared.

4. Conduct non-facilitated elicitation. (3 hours)

• Find and review existing documentation for the project
• Identify requirements reuse opportunities
• Get access to necessary applications and conduct user interface analysis (if applicable)

See part 2 of this series for details around the second day of Sprint 0!