During my PSM training sessions, I often get asked about the 3rd topic to be addressed during sprint planning. For people new to scrum, the training focuses sufficiently on the first 2 expectations of sprint planning, that they need to come up with the sprint goal, which is the ‘WHY’ we are doing this sprint and the ‘WHAT’ of the sprint, meaning the list of items that help us deliver that WHY.
Now coming to the 3rd expectation which is the ‘HOW’ of sprint planning, the Developers and only developers are expected to plan the work necessary to create an increment that meets the definition of Done. What does that mean and how much to do, is what I plan to discuss in this blog.
So to start with, the 2017 version of the scrum guide mentioned “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.” An understanding was that we should have work planned for the first 2-3 days of the sprint by the end of sprint planning session, so that we can use the daily scrum to further add the work to the sprint backlog that is needed to achieve the sprint goal. The idea was always to not plan complex work in great detail as that only leads to accumulation of waste.
With the 2020 revision of the scrum guide, it has become even less prescriptive by removing the element that mentioned ‘the first few days’, leaving the interpretation open to the users to plan the work necessary as you see fit and inspect & adapt as you move forward which is at the core of scrum.
Even then, people new to scrum need to know, how to get started and thus I share some experience how I have helped new scrum teams to plan by providing them a baseline.
Based on the definition of Done applicable for your product, think of tasks that you can add to your Sprint backlog items that help scrum teams create transparency and use inspection and adaptation to plan based on facts. Could the below list help you get started with your creation of plans for the first few days of the sprint?
Code/Implementation
Unit test
Bug Fixes
Server Side Code & Content layer update
Code Review
PO Review
Analysis of requirements and ACs
Design of Test Cases
Peer Review
Review of Test Cases
Execution of Test Cases
Retest of defects
Create Automation Logical Structure
Develop of Automation Test Scripts
Automation Code Review
Functional Review and Parallel Execution
Execution of Automation Test Scripts
ADA Dev Testing
ADA Manual Testing
The idea is always for the developers to decide whats works best for them. But can we use as a baseline to get the discussion going.
If you scrum team plans to release to production at least once a sprint, could below tasks makes sense?
Conduct Static and Dynamic PIC scans
Architecture code review
Code Refactoring
UAT testing plan review and execution
UAT server automation
Automation regression
Defect remediation
Load and Performance test
Splunk dashboard review
Prod Deployment approval
Production script review
The most important rule in Scrum is that every sprint should deliver a done increment. If you don’t have a done increment at the end of sprint, you are not doing scrum. That is the core artifact expected in scrum that allows to inspect and adapt and if you don’t have it, your entire feedback could be flawed that will make things worse. So depending on the Scrum teams definition of Done and the maturity of engineering practices, scrum teams should have a basic minimum set of tasks needed to deliver a done increment and most often it starts with a written checklist for the team to follow till they mature by delivering value consistently.