Sprint Planning Anti-Pattern — Missing Collective Ownership

Missing Ownership

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 going through the whole process to figure out the root cause 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 basic customer details.

• Analysis — 4 Hours — Farhan
• UI Design — 6 Hours — Farhan
• Coding — 8 Hours — Farhan
• Unit Testing — 2 Hours — Farhan
• Code Review — 2 Hours — Kaushik
• Documentation — 2 Hours — Kavya
• Document Review — 2 Hours — John
• Writing Test Cases — 4 Hours — Karan
• Test Case Review — 2 Hours — Diya
• Testing — 6 Hours — Karan
• Integration Testing — 2 Hours — Farhan

Automate opening loan page for agent-based on customer type with basic customer details.

• Analysis — 4 Hours — Nishchint
• UI Design — 6 Hours — Nishchint
• Coding — 8 Hours — Nishchint
• Unit Testing — 2 Hours — Nishchint
• Code Review — 2 Hours — Kaushik
• Documentation — 2 Hours — Kavya
• Document Review — 2 Hours — John
• Writing Test Cases — 4 Hours — Neha
• Test Case Review — 2 Hours — Diya
• Testing — 6 Hours — Neha
• Integration Testing — 2 Hours — Nishchint

There were similar tasks for the remaining two stories as well.

Good news that the Scrum team invited me as an observer for their next sprint planning and here is what I witnessed.

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 to every PBIs. The team did it in 30 mins! The remaining 30 mins discussion was unrelated to planning (also useless).
• 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 attaching pre-planned tasks to each story.
• 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 and stories 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.

What will you suggest to this team? All the ideas are welcome for my next blog. Feel free to write to me if you wanted to know how to avoid it at naveen@agilemania.com