Agile Buddha
Demystifying Agile, Getting to its Core
Story point is a unit of measure of estimation for the overall size of the work that will be required to fully implement a user story.
Story point has no direct relation with time even though people may get tempted to map it with time in order to get an hourly estimate to complete a user story.
To understand story point concept better, it’ll help to take an analogy with distance.
One of the popular mechanisms to estimate story points as a team is planning poker exercise.
It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.
Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.
It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.
But that’s not the point!
[Read more…] about Planning Poker is NOT about Agile Estimation!
In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.
Note: People landing on this post directly, please read earlier post to get context of the problem.
This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.
[Read more…] about Streamline Your UAT and DevOps – Kanban Boards
In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.
Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:
Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).
[Read more…] about Use Planning Board for Product Backlog Grooming
As long as customer isn’t interested in throughput or customer trusts the team, whatever way you size or estimate doesn’t really matter. But that doesn’t happen very often. Whenever customer questions about team throughput, it becomes challenging to answer using hour-based estimation as time taken to complete any particular task deflates over time.
Some teams follow capacity based estimation technique where they identify the number of hours available in a team for the entire sprint duration. Based on that they pick up stories in a sprint. Again here as well, there is absolutely no way to know any change in team throughput as size for which capacity is defined isn’t defined.
[Read more…] about FAQ: Why Story points? Why not map story points with time? What’s the issue?