Story Points Vs Time Estimating

My final post in this area brings me to another point which is often a popular debate subject.  Now it is important to remember that every team is different and every teams interpretation or implementation if Agile will differ. The key fact to remember is that it is important to find a implementation that works for your team – as at the end of the day the key point is you want to have a team that is efficient, effective at meeting delivery targets and ideally happy!

My personal take on this is to use story point estimation for user stories in the backlog, which then enables a team to quickly estimate (ideally a degree of confidence!) how long it would take to complete a set or even all stories (stories of course equate to work) left in the product backlog.  For this to be accurate, it is important the sprint velocity is recorded which is the measurement of how many story points a team completes typically per sprint.

When planning for a specific sprint it is important to examine and analyse the selected stories based on priority, then break these into further detail i.e. Technical tasks. These tasks will be estimated individually in time.  It will then be the responsibility of the developer to update their stories and tasks with time spent, effort remaining and any changes in overall status (i.e. In-progress, blocked, complete etc).

I believe that time based tracking during the sprint is key as it enables effective tracking on a day to day basis of overall progress. Effective tracking will then enable the SCRUM master or team to quickly identify any potential issues they may arise due to issues with tasks taking longer than expected for example.

Some developers can be resistance to the use of time tracking, as they may see this as a means of big brother watching them.  Or that feel the overhead of updating tickets daily with this data – is a waste of effort.  In reality it only takes a few minutes to update tickets if done daily and the purpose of time tracking is not highlight individual developer deficiencies, but simply to facilitate analysis overall sprint progress and help identify where tasks may commonly cause issue.

It is also important each member of the teams daily time utilisation is reviewed.  It is typically expected that a single full-time employee should be utilised around 70% to 75% of their daily total time available.  (Please note – I’m not saying people should only work for this portion of each day!!) This percentage may need to be re-considered based on the role a team member has.  Senior team members may be less effective as they are expected to help mentor other developers, attend more meetings and review code for example.  Members of the team with management responsibility may have other requirements such as line management tasks, managerial meetings, report writing etc.  This is in addition to typical interruptions that may occur during the course of a typical day that effect everyone.  On the flip-side, other types of workers such as remote workers may be able to achieve a higher daily utilisation percentage as they have less interruptions and meetings to attend for example.

Hence I believe the combination of the two techniques works best. Story point based estimation is at its most effective when considering items to be added to the backlog at a high level. Team games during planning such as planning poker can be used to negotiate points based on perceived complexity & risk. When stories are ready to be planned into the next sprint or two, they can then be developed further. This may involve further meetings with stakeholders, lower level requirements specification – which will ultimately allow technical tasks to be derived with time based estimates.