I was recently involved in a meeting with a team that wanted to change story points of a User Story that they committed to deliver in the middle of the sprint. As much weird as it sounds, it did happen though and I was there.
My first reaction was : Why?
Story points are a way of estimating the overall size of the User Story - Size includes effort, complexity and uncertainty. So if, during the implementation of the User Story, the team finds out that they estimated the size incorrectly (any of the 3 parts could have been wrongly estimated), teams should drop the User Story from current sprint and send it back to the backlog for further refinement.
The reason is two folds:
1. Team is not good at estimating size.
2. User Story authors left too many things open to interpretation and team ignored those signs during story pint estimation
How can you try to address it?
1. Spend first 2-3 sprints in defining (or identifying) the User Stories that can be referred in later sprints. In the end, no estimation should be by gut feeling. There has to be verified baseline to work with. Most of the teams I have worked with forget to do this.
2. Prepare User Story structure in which scope of open ended specification is less. For Example: A Use story for a web page that has a grid needs to mention following - default sorting order, can user sort, default paging size, can user change page size, does grid have to refresh in place or are we ok to reload the page, Is the grid readonly or will user be able to update/delete/add a row, will grid hide columns if user resizes the page, will grid have its own scrollbar etc. In the end team needs to sets standards in terms of accepting a User Stories and things will follow.
My first reaction was : Why?
Story points are a way of estimating the overall size of the User Story - Size includes effort, complexity and uncertainty. So if, during the implementation of the User Story, the team finds out that they estimated the size incorrectly (any of the 3 parts could have been wrongly estimated), teams should drop the User Story from current sprint and send it back to the backlog for further refinement.
The reason is two folds:
1. Team is not good at estimating size.
2. User Story authors left too many things open to interpretation and team ignored those signs during story pint estimation
How can you try to address it?
1. Spend first 2-3 sprints in defining (or identifying) the User Stories that can be referred in later sprints. In the end, no estimation should be by gut feeling. There has to be verified baseline to work with. Most of the teams I have worked with forget to do this.
2. Prepare User Story structure in which scope of open ended specification is less. For Example: A Use story for a web page that has a grid needs to mention following - default sorting order, can user sort, default paging size, can user change page size, does grid have to refresh in place or are we ok to reload the page, Is the grid readonly or will user be able to update/delete/add a row, will grid hide columns if user resizes the page, will grid have its own scrollbar etc. In the end team needs to sets standards in terms of accepting a User Stories and things will follow.
No comments:
Post a Comment