Since two sprints, we are noticing that the sprint planning meetings are going over 4 to 5 hours! Sometimes, we can't get a conference room, and we are forced to split it into two sessions.
After analyzing the reasons for these long meetings, we realized that our stories were complex and most of the time was spent in discussing requirements in the sprint planning meeting. Many times product owners ended up changing stories after discussing them with the engineers. Product Owners learn about technical dependencies over other stories or they choose to break up a story in a different way after discussions with engineers. Engineers even point out inconsistencies in the stories e.g. xyz tab lists contacts in ascending order, why is the order different on this tab? Most importantly, many times engineers pointed out the missing pieces in the stories.
This dialog between product owners and engineers needs to happen on consistent basis rather than just in a sprint planning meeting. Product owners should consult with experienced team members after writing a story. They can forward the newly written story to an experienced team member and ask for his/her feedback. They can ask the engineers to estimate points for the stories so that they can decide whether to break the story or not.
The team should help product owners to evolve stories. We have constituted a weekly hour long meeting for playing planning poker. Planning poker forces the much needed discussion about future stories between the product owner and the team. But these planning pokers are not sufficient as the focus of the meeting is just to know enough about story so that it can be scored. They should be supported by informal hallway discussions and mailing list questions.
Showing posts with label scrum planning. Show all posts
Showing posts with label scrum planning. Show all posts
Saturday, May 17, 2008
Tuesday, April 8, 2008
Point Score and Work Remaining in hours
A day before sprint 1 was about to end, the scrum master, team manager and scrum-trained developer were sitting in a meeting room trying to figure out the co-relation between velocity and estimated hours. The question in front of them was - What is the guideline for the team to choose stories? Should we give them a velocity number or the team should make a decision based on total number of available developer hours?
If we are going to use the total number of available hours for picking up stories from the backlog then what is the purpose of velocity? Why do we estimate stories in points? Why use different units? Why not just use hours so that this whole estimation is uniform in hours ?
They had only one sprint worth of data. The team was new to Scrum. The manager felt strongly that they should give some guideline to the team so that the team does not overburden itself or does not take up little work. He also wanted to know the correlation between points and hours.
Here is what Ken Schwaber says in his book - Agile Software Development with Scrum
"This (in our case the questions raised above) question indicates the difficulty shifting from a pert chart-based, time reporting structure to an empirical approach"
There is a difference between assigning a point score for a story and estimating hours for a story. Point score is the effort. Work remaining is the time (hours). The point score for a story is an approximate score. This score is used in velocity calculations. Product owner and the scrum master use this for release estimation and planning.
The team only uses estimated hours while picking stories for a sprint. They pick a story from the backlog and estimate the number of hours after clarifying requirements with the product owner. Estimating hours require more understanding of the story than assigning a very rough point score. Furthermore, estimation should be preferably done for tasks - at a finer granularity than story. A story should be divided into multiple tasks such as testing, coding, writing unit tests, coding UI layer etc. That makes a story more predictable. The team only deals in number of hours and specifically remaining number of hours. On realizing this, the manager stopped deriving the correlation between effort and time.
If we are going to use the total number of available hours for picking up stories from the backlog then what is the purpose of velocity? Why do we estimate stories in points? Why use different units? Why not just use hours so that this whole estimation is uniform in hours ?
They had only one sprint worth of data. The team was new to Scrum. The manager felt strongly that they should give some guideline to the team so that the team does not overburden itself or does not take up little work. He also wanted to know the correlation between points and hours.
Here is what Ken Schwaber says in his book - Agile Software Development with Scrum
"This (in our case the questions raised above) question indicates the difficulty shifting from a pert chart-based, time reporting structure to an empirical approach"There is a difference between assigning a point score for a story and estimating hours for a story. Point score is the effort. Work remaining is the time (hours). The point score for a story is an approximate score. This score is used in velocity calculations. Product owner and the scrum master use this for release estimation and planning.
The team only uses estimated hours while picking stories for a sprint. They pick a story from the backlog and estimate the number of hours after clarifying requirements with the product owner. Estimating hours require more understanding of the story than assigning a very rough point score. Furthermore, estimation should be preferably done for tasks - at a finer granularity than story. A story should be divided into multiple tasks such as testing, coding, writing unit tests, coding UI layer etc. That makes a story more predictable. The team only deals in number of hours and specifically remaining number of hours. On realizing this, the manager stopped deriving the correlation between effort and time.
Subscribe to:
Posts (Atom)
