Anti-patterns of Sprint Planning – Task Creation

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

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. 

Author's Bio

Naveen Kumar Singh

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.