Agile Time vs Story Points
The company I work for is trying to adhere for agile framework for a long time, but due to varies reasons we haven’t succeed. Suddenly we have been pushed to do agile and get the velocity etc.
Even though we applied some basic agile principles we didn’t do things such as sizing. So we started, I got six members on my team with varies levels of experience in software engineering. Some had little bit of experience in agile and some never knew what is agile. So had to train them with my experience on agile for past few years in a different company.
So I picked few tasks from our backlog and created a sprint. Now the question was how to do the sizing. As nobody had idea on how to do a sizing it was bit difficult to start with.
Story sizing is used to document the complexity of the task more mathematically. Sizing is done using 0, 1, 2, 3, 5, 8, 13, 21 etc. First task to size is selected as the reference task that can be done not too easily and not too hard. Then we sized rest of the tasks compared to the reference task with the relative complexity.
3 was okay
2 is easy and 1 is very easy
5 is hard and 13 is very hard
When we doing sizing we should make sure, sizing is done independently. Most of the time in my experience sizing is given based on others judgements. In order to get a better sizing all should aware what is task supposed to do and give their inputs. Who has the better overview should explain the background for those who has no idea of the task.
All have been instructed to have their mobile phones ready with calculator open and do the sizing secretly. Once sizing is ready all at once should show the screen what they got. Then we will argue on numbers if they are different and come to a conclusion based on majority vote.
Finally back to famous agile question how to map those story points to hours. Theoretically there is no relationship between time and points. But then how we can estimate the time for a task. This is a place where even I had no clear view of how to. So had to do a bit of google and came to the following conclusion.
Even though book says we shouldn’t map time to points, we need to map them to do get the estimated time for a task. One idea was to consider one story point is one day. But this was a clean waste of what did on sizing.
So this is how it should be done as my understanding, time to point ratio should be extracted from number of points divided by time of the sprint.
If you starting your first sprint, then you will have no idea of how many story points to take into your sprint. Again here we should be applying same principle we practised while sizing a story. In the initial sprint we will select random number of story points that we think we can finish within our sprint. This can be totally wrong … doesn’t matter. Now you can get the time for a single story point which will be valid for the current sprint only by dividing time/points. Now we can divide the work load among team members and start the sprint.
Wait … yet haven’t finish our sizing.
Once our current sprint has been completed, we should conduct a sprint retrospective meeting and find where we went wrong or right. Probably you will find many issues like incorrect scope, size, requirements etc. Based on output from this meeting we should be able to analyse whether to change number of points to take in the next sprint, can be increased or reduced. For example if have 5 points haven’t completed, then will take 5 points less number of tasks in the next sprint.
If we are to alter the number of points taken in a sprint, then obviously our time/points ratio will be changed accordingly. That is why we always instructed not to match points to time, if yes we tend to do the sizing based on time to finish the task. Software industry now knows that’s not the best approach to get the complexity of a task.
Happy Coding!