Scrum tales - Part 7

Almost all developer teams have encountered this issue with their Sprints - how to define Sprint tasks and estimates when it is almost impossible to know all the individual steps needed upfront to get to the defined PBI goal - i.e. you just don't know where to start?
To some extent this also applies to other teams who cannot define their PBI individual tasks upfront during the Sprint planning meeting, so please read ahead and don't "guestimate" too much

1. Understand your goal / PBI - what exactly do you need to accomplish?
   a) Improve performance - where, by how much %, can this be perceived performance improvement vs. hacking open Windows drivers?
   b) Fix a stubborn Critical severity issue that you have no idea what is causing it - is there a workaround you can implement instead, can you at least fix it so that it is at least no longer considered Critical severity, can you research a bit to define how to proceed next?
   c) Build a new product or product feature - do you at least know the feature set needed if you don't have full specs or UI mockups?

2. Research - one thing that was rarely used or was used incorrectly are research tasks:
Yes - you can add research tasks to closer define actual tasks that will lead to the goal accomplishment
No - you cannot have an always open research task to work on during the whole length of the Sprint

Start by creating a finite research task that will allow you to figure out your exact next tasks towards the PBI endgoal. Limit yourself in research which must result in:
   1) New research tasks that are closer defined and can be shared amongst more team members
   2) Specific finite tasks to start working towards the goal

Specifically related to the hypothetical goals mentioned above:
   a) To improve performance start by defining tasks to:
   - test current version vs. previous versions of the product and isolate speed difference
   - test comps and isolate speed difference
   - research code to isolate bottlenecks
   - research bottlenecks to prioritize them starting with easy fixes (perceived performance improvements) to complex driver hacks

   b) To fix a bug when you have no idea what is causing it, define tasks to:
   - research code to find workarounds or at least new more specific research areas
   - research new specific areas for possible fixes and list them from easiest (quick workarounds) to most complex ones (redesign engines) and estimate each one

   c) To build a new product knowing only a closed feature set, define tasks to:
   - research comps and create new design tasks
   - research features functionality how to technically implement them and what all will be needed to do this; define design tasks

3. Define achievable tasks with real estimates

Scrum is different from the Waterfall model in that it doesn't require you to know all the How specifics before starting to sprint. Scrum team must clearly understand the goal (PBI) but can figure out how to achieve it during the sprint itself

It is important however to note that research tasks must also be finite and they must result in new research tasks or concrete development tasks leading you one step closer to the goal