Skip to main content

Planning and Estimation

Last post 04:48 pm November 25, 2019 by Harshal Rathee
3 replies
06:54 am November 21, 2019

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


09:44 am November 21, 2019

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?


11:14 am November 25, 2019

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?


04:48 pm November 25, 2019

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 ? 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.