Why do we need tasks? What is the need of Planned, Actual and Remaining hours?

 

I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks?  Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.

The recommendation is to have tasks created for each story.  Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria.  Once tasks are created, each task should be tagged to approx. hours needed for the same.

While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to

  • Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
  • Dependency
  • Constraints
  • Acceptance criteria

The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming.  It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.

I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining

  • The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
  • It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
  • Having tasks for individual story make it very easy to share your story work with other team members.
  • The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
  • The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
  • Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
  • Small victories (after completing each tasks) gives motivation to individuals.
  • You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
  • The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
  • In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
  • The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
  • These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
  • The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
  • The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
  • Better bonding within team as things are BETTER organized.
  • You can better calculate matrices like productivity, cycle time, utilization etc.

Leave a Reply

Your email address will not be published. Required fields are marked *