Burn Your Points Before They Expire

How many of you have experienced situations such as above where your customer or your product owner questions about the amount of work completed? Inadvertently your efficiency, work ethic or commitment is being questioned here. I’m sure many of you who are part of an Agile team may have faced a similar situation.

So, how have you responded to such a question from your customer? How have you managed their expectations in terms of solution delivery and timelines? The question is more to do with making your progress visible. How have you managed to do so? Here are the Agile Practices for Distributed Teams.

I’ve even come across situations where teams struggle to respond to these sort of questions where they meekly stumble with an answer such as, “Hey John, we burned five story points yesterday. We still have three points remaining to complete that story.” Most of the time the response is given just to get the customer off your back or just to keep him satisfied though it is not the reality.

This type of questions where progress is questioned is common in organizations that are adopting Scrum for the first time or are new to Agile. Some are cases in which the Scrum Master or product owner (PO) is assigned from the customer side or from a non-technical background. But, come to think of it, a customer asking such questions makes sense, because their primary objectives are to make sure that,

• The solution is delivered according to the Triple Constraints (time, cost, and quality) defined for the project
• The time to market is acceptable and that the solution generates revenue before competing products capture the market space

Guide Comparing Agile Tools [Free PDF]

Can you count down the story points?

In terms of Agile principles, are the above questions actually valid? Can you really give a count of how many story points you have burnt? Can you quantify the remaining effort mid sprint in terms of story points?

The answer is an emphatic “No, You can’t!!”
As we all know, estimations in Agile are based on ‘Relative sizing’. The team selects a well-groomed, reasonably sized user story (based on complexity or value) as the ‘base’ story. The team then agrees on a story point value for that particular story. Let’s say, as an example, story A is of size 2.

Then the team goes through the rest of the user stories in the product backlog assigning story point values to each story comparing against the base story. This we all know and is said to be the core principle of sizing in Agile. In order for this process to work the selected set of stories in the product backlog must be adequately detailed out with appropriate acceptance criteria, validation rules, wireframes, examples etc.

During sprint planning, the team then decides on the list of tasks required to complete each story and specifies how long a particular task may take in terms of hours. The PO explains the feature in detail allowing the implementation team to clarify doubts thus enabling them to identify an exhaustive list of tasks needed to complete that particular feature.

Another misconception…

So, another question that is asked frequently is, “Is there a direct relationship between the story point number assigned to a user story and the number of hours determined for the whole story?”. In other words the question is whether 1 story point equate to ‘X’ number of hours.

Again, the answer is an overwhelming “No!!”. You might have a user story of 5 story points assigned with 20 hours worth of effort, and another story of 3 story points assigned 20 hours of effort. It all depends on the maturity and the gut feeling of the team at the time of sprint planning and estimating in terms of identifying the tasks required to complete the work along with the time that would be taken to complete each task.

Ongoing time reporting, a good practice in Agile…

I now circle back to our initial question about story points burnt. The team reports time spent on each task and updates the remaining time to complete each task. Note that the time spent and time remaining is updated in hours. So the total amount of time left to complete a story can be calculated day-by-day by summing up the remaining amount of hours for each task. This is what gets reflected on your burn-down chart.

Note that you never update nor change your initial estimation of story points assigned for your story or indicate that you have ‘X’ amount of story points worth of work remaining.

So, the logical answer you should give your PO if he asks you a question about story points burnt is, “I’ve burnt six hours of effort yesterday, and I have three hours of effort remaining to complete the user story ABC.”

Unable to complete user stories during the sprint? Not to worry!!

Finally, what if the team is unable to complete a user story taken up during a sprint? Does the number of story points assigned get added to the velocity? For example, can we say out of a 8-point user story, we completed 5 points and that should get added to the velocity? Again, No!

User stories that are not completed during the given sprint are moved to the product backlog or a new user story is created for the remaining work in which case the previously defined user story is closed. The story added to the product backlog is reprioritized and re-estimated.

For example, an unfinished user story of size 8, of which a certain percentage of work was completed during the previous sprint, may be re-estimated to be of 5 story points and thus brought forward to a subsequent sprint. 3 story points will not get added as amount of work completed during the previous sprint and will not be reflected on the sprint burndown chart.

Acquire the expertise and understanding to effectively manage triumphant projects with PRINCE2 course. Fulfill KnowledgeHut's PRINCE2 practitioner prerequisites and unleash your potential. Enroll now!

I hope this all makes sense. The next time someone asks you the questions at the beginning of this article, you now know what to say!!