sprint-planningWe often see team create tasks for product backlog items during sprint planning but those tasks are skill-based task like coding, testing, documentations etc. Is it a right way to do? What all can go wrong if we keep creating tasks like this?

I was in meeting with a team and one of team member asked question related to daily scrum. Question was – why to have daily scrum?

We all know daily scrum is an important inspect-adapt event but what if team don’t find it useful? Why it was not helpful for them? We starting going through the whole process and found that sprint planning is real culprit.

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 customer basic details.
  • Generate single view of all investments for a particular customer based on customer Id.
  • Automate opening loan page for agent based on customer type with customer basic details.
  • Generate single view of all loan 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 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 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?

  • Team internally get divided in 2 parts. One developer and one tester for a PBI. That’s fine but order of execution also change. If they fails to deliver all 4 and deliver only 2 then none of functionality will complete for use.
  • Obviously none of team is interested in hearing other part of work. Since Daily Scrum is for team and team not interested in each other work then why to have daily scrum?
  • Sprint planning was not even lasting 1 hour for 2 weeks sprint because story was understood by team during PBR and velocity is known so team was picking up items from ordered product backlog. Since team is creating skilled based task so task usually remain same for all PBIs. Team was just attaching those standard tasks for every PBIs. Done in 30 mins!
  • Team has not discussed about 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 was many more issues related poor planning such as delayed feedback, bigger batch size and choking workflow etc. Will share those sometime during face to face discussion.

What can be done to avoid such issues?

  • No skilled based task. Better not to create task at all but still needed then component wise task
  • Avoid tools for sprint planning and sprint backlog
  • Task must emerge while discussing approach and design
  • Whole team approach
  • Don’t change PBI order
  • Focus should be to complete one PBI at a time. If team feels there is not enough to do for whole team for one PBI then only start next PBI
  • Frequent integration of code
  • Smaller batch size to maintain flow and improve feedback loop