Planning and Estimation
How can a team that is not inclined to using "velocity" as a way to measure its ability to complete work each iteration decide how much it can do in a sprint planning meeting? Some obvious answer(s) : # of back log items delivered sprint on sprint, or just based of everyone's agreement / gut?
How can a team that has subject matter experts (SME) in their own areas of the application, do estimation, as planning poker is percieved to be ineffective? To add to that, the developers not having idea on what/how of the testing, and an SME not knowing about the area of other SME? Obvious answer/way: encouraging to be cross functional.
Looking for some guidance on the above two challenges.
Thanks,
Niranjan
team that is not inclined to using "velocity" as a way to measure
Did you inspect why this is?
measure its ability to complete work each iteration
How does your team measure this? Or even better, how do you think reliable forecasts and sprint goal commitments can be formed? Where are the leading and laging indicators you DO want to adopt?
gut?
Since when is one person's gut a transparent and reliable factor? How does the team feel about relying on someone's gut for estimation, forecasting, predictability and transparency?
How can a team that has subject matter experts (SME) in their own areas of the application, do estimation,
How does having SME's change the way estimation is done?
as planning poker is percieved to be ineffective?
Did you inspect why this is?
the developers not having idea on what/how of the testing, and an SME not knowing about the area of other SME?
What is the teams view on improving this?
How can a team that has subject matter experts (SME) in their own areas of the application, do estimation, as planning poker is percieved to be ineffective?
Ineffective at what?
Doesn't planning poker cause team members to discuss areas of the application with which they may not be familiar, and thereby help improve shared understanding? If not, why not?
How can a team that is not inclined to using "velocity" as a way to measure its ability to complete work each iteration decide how much it can do in a sprint planning meeting? Some obvious answer(s) : # of back log items delivered sprint on sprint, or just based of everyone's agreement / gut?
How does your team currently make a forecast for Goal and scope ? Do they reach their committed Goal at the end ?
How can a team that has subject matter experts (SME) in their own areas of the application, do estimation, as planning poker is percieved to be ineffective? To add to that, the developers not having idea on what/how of the testing, and an SME not knowing about the area of other SME? Obvious answer/way: encouraging to be cross functional.
How entire team sits and vote for a task without having much information about it ? How do you reach to an agreement to have one common estimation for any task ? Does planning poker brings enough insights for your team ?