We often see teams create tasks for product backlog items during sprint planning, but those tasks are skill-based tasks like coding, testing, documentation, etc. Is it the right way to do it? What can all go wrong if we keep creating tasks like this?
I was in a meeting with a team, and one of the team members asked a question related to daily scrum. The question was – why have daily scrum?
We all know daily scrum is a critical inspect and adapt event but what if the team doesn’t find it useful? Why was it not helpful for them? We were starting to go through the whole process and found that sprint planning is the real culprit.
The team shared their sprint backlog, which was something like below:-
Product Backlog Items for current sprint –
- Automate opening investment page for agent-based on customer type with basic customer details.
- Generate a single view of all investments for a particular customer based on customer Id.
- Automate opening loan page for agent-based on customer type with basic customer details.
- Generate a single view of all loans for a particular customer based on customer Id.
Tasks board
Automate opening investment page for agent-based on customer type with customer basic details. | ||
Analysis | 4 | Farhan |
UI Design | 6 | Farhan |
Coding | 8 | Farhan |
Unit Testing | 2 | Farhan |
Code Review | 2 | Kaushik |
Documentation | 2 | Kavya |
Document Review | 2 | John |
Writing Test Cases | 4 | Karan |
Test Case Review | 2 | Diya |
Testing | 6 | Karan |
Integration Testing | 2 | Farhan |
Automate opening loan page for agent-based on customer type with customer basic details. | ||
Analysis | 4 | Nishchint |
UI Design | 6 | Nishchint |
Coding | 8 | Nishchint |
Unit Testing | 2 | Nishchint |
Code Review | 2 | Kaushik |
Documentation | 2 | Kavya |
Document Review | 2 | John |
Writing Test Cases | 4 | Neha |
Test Case Review | 2 | Diya |
Testing | 6 | Neha |
Integration Testing | 2 | Nishchint |
Generate a single view of all investments for a particular customer based on customer Id. | ||
Analysis | 4 | Farhan |
UI Design | 6 | Farhan |
Coding | 8 | Farhan |
Unit Testing | 2 | Farhan |
Code Review | 2 | Kaushik |
Documentation | 2 | Kavya |
Document Review | 2 | John |
Writing Test Cases | 4 | Karan |
Test Case Review | 2 | Diya |
Testing | 6 | Karan |
Integration Testing | 2 | Farhan |
Generate a single view of all loan for a particular customer based on customer. | ||
Analysis | 4 | Nishchint |
UI Design | 6 | Nishchint |
Coding | 8 | Nishchint |
Unit Testing | 2 | Nishchint |
Code Review | 2 | Kaushik |
Documentation | 2 | Kavya |
Document Review | 2 | John |
Writing Test Cases | 4 | Neha |
Test Case Review | 2 | Diya |
Testing | 6 | Neha |
Integration Testing | 2 | Nishchint |
What is happening here?
- The team internally gets divided into multiple parts to take care of their work based on skills, not looking at the whole story. Everyone was demonstrating waterfall (sequential) behavior.
- None of the team members were interested in hearing other parts of the work. Since Daily Scrum is for team and team not interested in each other’s work, why do they have daily scrum?
- Sprint planning lasted 1 hour for two weeks sprint because they knew stories, as they have refined during PBR. The velocity is well known, so the team was picking up items from the ordered product backlog. Since the team is creating a skilled-based task, tasks usually remain the same for all PBIs, so it didn’t take much time. The team was attaching those standard tasks for every PBIs. It was done in 30 mins!
- The team has not discussed design and architecture during planning; otherwise, those could have been visible on board. Result? Duplicate code to avoid dependencies on each other, but who cares about technical debts and code smells?
- There were many more issues related to poor planning, such as delayed feedback, bigger batch size and choking workflow, etc. I will share those sometime during the face-to-face discussion.
- The Sprint Goal was missing!!
What can we do to avoid such issues?
- No skilled-based task. Better not to create tasks at all but still needed than component-wise tasks may be a better option like front-end, service, integration, etc.
- Avoid tools such as Jira for sprint planning and use a physical board or online board to visualize and facilitate team Collaboration.
- The task must emerge while discussing approach and design rather than pre-planned.
- The whole team approach needed to have collective ownership.
- The focus should be to complete one PBI at a time. If the team feels there is not enough work for everyone for the whole team to complete one PBI, then start the next PBI.
- Frequent integration of code is essential to reduce technical debt.
- Smaller batch size to maintain flow and improve the feedback loop
Most importantly, commit to the Sprint Goal, not to the plan. Inspect and adapt the sprint plan daily as work progresses.
Naveen is a Lean-Agile Coach, Professional Scrum Trainer (PST) and Internationally acclaimed Speaker in many Conferences and Agile events. He has over 22 years of experience in multiple domains and he is a Certified LeSS Practitioner (Large-Scale Scrum) and one of the early adopters of DevOps practices and teaches DevOps culture around the Globe.
Hi naveen
Any specific reason to Avoid tools for sprint planning and sprint backlog?
What is benifit of same?
Kshitij, tools are distracter for better sprint planning. Team seating together without tools discuss more about design and approach to meet sprint goal. Team with tools focus more on filling fields in tools.
Tools for sprint backlog is not good but can’t avoid in case of distributed team. Co-located team works well with physical board and stickies. Physical board create more transparency and help team to stay focus to goal.
Hello Naveen – How come skill based task is different than component based task? Sorry, little confused. Will be good for all of us, if you give an example.