I am a Senior Business Analyst with 8+ years of experience in Business Analysis, Product Management and Software Development.
Sprint planning is one of the most important event in scrum. If done correctly, it can be a ladder to turn vision into a successful and valuable product.
In my professional experience as a developer and as a business analyst, I have been a part of many sprint planning meetings, both - good and bad. In this article, I am going to share my complete knowledge and experience about this event.
What is Sprint Planning?
Sprint planning is an event that kicks off/starts the sprint.
Quick peek on - what is sprint?
Sprint is a set period of time (for example 10 days) in which development team completes a set amount of work.
So now we know that what is sprint. As definition goes, there is a set amount of work which is required to be completed in sprint. This set amount of work is discussed, planned and estimated in sprint planning.
This makes sprint planning one of the most crucial event. Why? Because of sprint planning is done correctly then it can direct development towards required end result. But if done incorrectly, it can lead to catastrophic failure and loss in all departments i.e. time, effort and money.
Who participates in sprint planning?
By definition, following team members participates in sprint planning:
- Product Owner
- Development Team
- Scrum Master
Responsibilities of each role
- Product owner is the person who focuses on value maximisation.On the basis of that product backlog is priortised. So he always see that ideally every sprint should deliver value to end user.
- It is important to understand that all product backlog items are not discussed in sprint planning. Based on prioritisation and value delivery, product owner keeps a subset of product backlog items for discussion.
- This subset of product backlog defines sprint goal and sprint backlog. Both these artifacts are defined in collaboration with development team.
- Development team is the soul of product development. Without them there is no tangible product.
- Development team decides that how much work can be picked up for a sprint. That is why sprint goal and backlog cannot be set without development team collaboration.
- During sprint planning, development team members need to understand all the product backlog items which can be picked for sprint.
- They need to and should be asking as many questions as possible in this sprint planning meeting.
- Once they get answer to all their questions, then they can break down product backlog items or user stories into tasks. Which can be then estimated.
- Scrum master makes sure the scrum guidelines are followed during sprint planning meeting.
- He will make sure that there is proper cohesive collaboration between product owner and development team.
- Scrum master educates team on task estimation process. There is no set criteria for this. Every product team can have a different process of estimation. Scrum master makes sure that whole scrum team is aware about it.
- Scrum master is a neutral party. They don't share opinion during sprint planning. But they make sure that nothing derails the sprint planning so that it can be completed in set time-box.
- It is very important to highlight Business Analyst role in this whole process.
- Business Analyst is a person who can be considered as a part of development team because he enables product development. But he works closely with Product Owner.
- Product owner is responsible for product requirement discovery. Once that is done, product owner has a list of product backlog items.
- Business Analyst understands the requirements from product owner. On the basis of understanding, Business Analyst picks up product backlog items and convert these into detailed and well-groomed user stories.
- These user stories are discussed during sprint planning.
- Development team questions are usually taken up by both - Product Owner and Business Analyst.
What preparation is required before sprint planning?
It’s simple to understand. For sprint planning we need user stories because those user stories are discussed and planned in sprint planning.
- Hence before sprint planning meeting, product owner and business analyst are in main focal point.
- Product owner defines the prioritisation of product backlog items that can be picked up for discussion in sprint planning.
- Business Analyst takes download from product owner and accordingly grooms the work items.
- During grooming, business analyst makes sure that mock ups or wireframes. These mock ups are attached in the user stories. Business analyst also checks for all the RAID points. RAID includes Risks, Assumptions, Issues and Dependencies. Business analyst along with product owner closes all RAID points before sprint planning. It is important to close these points before development team plans these user stories. If not closed, it can lead to spill-overs, blockers and re-work. It is not good for product development from technical as well as business standpoint.
- During user story grooming, business analyst and product owner should keep in mind that they stick to the plan and sprint utility is always in focus. At times, we loose the sight of product backlog items, hence it messes up the prioritisation and grooming
- It is important to understand that during product development, there can be technical user stories as well. In these stories, we don’t put business requirement points. These stories are created for describing technical approach. For such stories, business analyst or product owner can groom in collaboration with development. Following three inputs should come from development team side – objective of user story, technical approach to achieve it, what will be the outcome of this user story.
- Before sprint planning, business analyst should make sure that tech lead or tech architect is given download of user stories on high level in some sort of technical review call. This will help during sprint planning call. If a technical review call is done prior to sprint planning call then there are certain advantages to it :1. If a senior technical team member gets the idea of requirements, then it helps business analyst and product owner during sprint planning meeting. Development team gets holistic understanding on what is required, why it is required and how it can be achieved. 2. In technical review call, team don’t have any pressures to provide effort estimation, so they can think freely and ask as many queries as possible
How Sprint Planning is conducted
As a Business Analyst or Product Owner in any particular product, I make sure to prepare well before Sprint Planning.
- Apart from story grooming, I also make sure that I set a context for my team so that they can see every sprint like a part of bigger journeys.
- It is crucial for development team to relate themselves with backlog items like I do i.e. to think about it from end user's perspective.
- I prepare a small introduction before giving user stories details. In this introduction I address: What was done in last sprint, What needs to be planned for next sprint and Why it is required.
- Development team decides according to their capacity that what can be picked in a particular sprint. As BA or PO, it is our responsibility to enable development team to trust their decision.
- I try to identify all use cases, scenarios, edge cases, dependencies etc. before the sprint planning. Close points with relevant stakeholders. But sometimes, there might be a possibility that I may miss an edge case or a detail required in story. In such case don't sweat on it or think of yourself as a bad BA or PO. It can happen with anyone. Check how big an impact this miss is making and accordingly take decision.
- Don't read story line by line. Keep the mockups on screen and first walk them through the story journey. Then give team couple of minutes to read all the points.
- I try to keep vertical slicing in all my stories i.e. a user story is covering UI, business layer and backend layer. So division of sub tasks is kept accordingly.
- As BA or PO, I don't influence estimates provided by development team. But wherever necessary, I ask questions. I try to keep it simple in responsibility division i.e. I provide answer to 'What' and 'Why' and development team provides answer to 'How'.
- As a team we try to keep sprint planning within the set time-box. In my case it is 4 hours. It can 8 hours as well, depending on Sprint length.
Sprint planning is one of the most important time boxed event. As a part of IT industry we truly need to understand its importance. If done correctly, it can convert a vision into a successful product.
In future I will try to post an article around another side of this i.e. bad sprint planning culture and how it can lead organisation level impact. It will definitely give further clarification on importance of sprint planning.
Hope this article helps.
This content reflects the personal opinions of the author. It is accurate and true to the best of the author’s knowledge and should not be substituted for impartial fact or advice in legal, political, or personal matters.
© 2022 Manish Shukla