Anti-patterns of Sprint Planning – skill-based task creation

We 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?

  • Team may not focus on delivering end-to-end feature and every members are just concern about their respective tasks but what about whole feature?
  • Team members may not be interested in hearing other’s work so Daily Scrum may become boring for team and team may not be interested in each other work.
  • Sprint planning may get completed quickly without going in details. This may lead to poor planning for iteration.
  • Team may not discuss about design and architecture during planning and that will lead to duplicate code to avoid dependencies on each other during execution.

I will share my learning on how to plan sprint to avoid above issues. 


Outline/Structure of the Talk


Problem statement

Approach to solve this problem



Learning Outcome

 - Better approach for sprint planning
 - How to improve team collaboration by not creating skill-based tasks
 - List of activities to be avoided during sprint planning

Target Audience

Scrum enthusiast

schedule Submitted 4 years ago

  • Satisha Venkataramaiah

    Satisha Venkataramaiah - Extended Impact Mapping: Identifying the real problems that your product should solve.

    45 Mins

    People are the reasons why we build Products. Products are meant to solve a problem for the people. For example, if we are building a Car-pooling application in Bengaluru, we are trying to solve the problem of traffic jams. The car-pooling app won’t solve that problem but people do. The car-pooling app has to address the constraint that people face in pooling the car. One of the reasons why people may not car pool could be the issue of safety. If car-pooling app can’t address it people don’t car pool and vision can’t be achieved. Extended impact-mapping helps in understanding those constraints to help Product teams in helping the products features to address those constraints.


  • Satisha Venkataramaiah

    Satisha Venkataramaiah - Change Canvas – A technique to create a Shared Need for Organization Agility

    90 Mins

    If someone says we want to adopt Scrum or some other framework, there is always a problem that Scrum can solve for them. Many a time, people at the helm of helping Organizations solve that problem lose the focus on the problem and Scrum becomes their main goal. Change Canvas is a way to help everyone involved in Organization transformation stay focused on solving the underlying problem that Organization thought Scrum could solve. This technique uses 5 HOWs, Change mapping and Contributor Quadrant to build the canvas. This helps in using Scrum as an Organizational transformation framework rather than just a delivery framework. 

    In this 90-minute workshop, Satisha will help you build a Canvas for your problem.