4 ms·

Estimation games (poker planning) always worked perfectly for me, regardless of where I was working. It's a great tool for having everyone on the team to voice

by jacekm 7y ago

Estimation games (poker planning) always worked perfectly for me, regardless of where I was working. It's a great tool for having everyone on the team to voice their opinions. On some occasions where such games were abandoned I saw individuals putting unrealistic estimates on stories. While these individuals had a lot of experience they tended to estimate from their perspective and skillset, not taking into account that implementation may take more time for other team members. Story points is a different topic though. In one company I saw it working fine, but we tended to keep number of points per story low. If too many points were assigned, BAs were asked to rework the story and split it into smaller ones. In my current job we tend to associate story points with person-days (so for instance 5 story points is ~5 days of work) and I think it works well for us. > we know how many points we can estimate in a sprint Well, you learn your delivery capacity after first couple of sprints. After 3-4 sprints I usually expect my team to deliver roughly similar number of story points each sprint. If we don't it calls for an investigation. Sometimes there's a good reason (e.g. people on sick leaves or previously unforeseen problems) and we expect situation to stabilize over the next 1-2 sprints. Other times we need to take some actions. Also you may try assigning particular stories to particular people during planning meetings. Ideally they themselves should commit to deliver a particular number of stories. It may happen that some shuffling and reassigning will occur during sprint, but that's ok. The purpose of this exercise is to help you estimating how many story points you can deliver, the assignments are not that important. BTW it would be easier to answer if you could elaborate what problems exactly are you facing.

tdrgabi 7y ago
Usually a team of 4-5. 2 are more senior and know the code area. 3 developers are new or never worked in that area. You can ask the senior people to estimate or if you ask everyone, the juniors are aware they input random numbers. It feels like a charade. And the talk "why do you think it'a 4, mine is a 2" usually results in a shrug and it randomly becomes 2 or 4
- jacekm 7y ago
  It's ok to abstain from voting if you don't feel confident about providing an estimate for SOME of the tasks. However if team members cannot provide any input on any of the stories then you have a bigger problem. > usually results in a shrug This is a problem. I'd suggest to repeat voting after having a conversation. And like I've said before - developers should try to commit themselves to deliver a chunk of work. It's hard to commit to random estimate that does not take your point of view into account. You could also try replacing story points with t-shirt sizes. If you cannot agree whether the story is 2 or 4 points, maybe it would be easier to agree between M or L. I am not a big fan of this method but I've seen teams for whom it worked better than story points.
  - tdrgabi 7y ago
    Thank you for the in depth of answers.
- sethammons 7y ago
  We try to write stories to be clear enough that anyone on the team could work on it. Supporting documentation linked, code points linked, etc. It is not always needed, but can help, especially with newer folks. Still, if someone is sufficiently new or unfamiliar with a given topic, they can abstain from voting (and it usually means this person should be shadowing or pairing with someone else to deliver that story). For 2 vs 4, I've heard it recommended to use Fibonacci numbers to help avoid the confusion. 1, 2, 3, 5, 8... The argument being that with small points, usually things are easier to compare. As you get larger points, it is more apparent if something is a 5 vs 8. So a 2 vs 3? Meh, round up and move on to the next story. 2 vs 5? Orly? Let's talk on why these are (un)like similarly sized stories. However! Hemming and hawing over close point stories irks me, eps. when the story could have been half way done by the time the team negotiates the points. If points are slowing your team down or not aiding discussions about sizing, then your team should change how it operates; the process should be helping. We've changed ours method to 1, 2, or 3 (definitions what those mean to our team in another comment I left here). Pointing for us typically takes under 20 seconds. Everyone agrees? Good; done. Disagreements? Either round up or discuss it and move on. The end goal is to help the team create as small of stories that are still delivering value to the org. If any of your agile/scrum ceremonies are not adding value, the retro is a good place to discuss how to improve (or remove) processes so that the team can effectively and visibly make progress.

by jacekm 7y ago

tdrgabi 7y ago

Usually a team of 4-5. 2 are more senior and know the code area. 3 developers are new or never worked in that area. You can ask the senior people to estimate or if you ask everyone, the juniors are aware they input random numbers. It feels like a charade. And the talk "why do you think it'a 4, mine is a 2" usually results in a shrug and it randomly becomes 2 or 4

jacekm 7y ago
It's ok to abstain from voting if you don't feel confident about providing an estimate for SOME of the tasks. However if team members cannot provide any input on any of the stories then you have a bigger problem. > usually results in a shrug This is a problem. I'd suggest to repeat voting after having a conversation. And like I've said before - developers should try to commit themselves to deliver a chunk of work. It's hard to commit to random estimate that does not take your point of view into account. You could also try replacing story points with t-shirt sizes. If you cannot agree whether the story is 2 or 4 points, maybe it would be easier to agree between M or L. I am not a big fan of this method but I've seen teams for whom it worked better than story points.
- tdrgabi 7y ago
  Thank you for the in depth of answers.
sethammons 7y ago
We try to write stories to be clear enough that anyone on the team could work on it. Supporting documentation linked, code points linked, etc. It is not always needed, but can help, especially with newer folks. Still, if someone is sufficiently new or unfamiliar with a given topic, they can abstain from voting (and it usually means this person should be shadowing or pairing with someone else to deliver that story). For 2 vs 4, I've heard it recommended to use Fibonacci numbers to help avoid the confusion. 1, 2, 3, 5, 8... The argument being that with small points, usually things are easier to compare. As you get larger points, it is more apparent if something is a 5 vs 8. So a 2 vs 3? Meh, round up and move on to the next story. 2 vs 5? Orly? Let's talk on why these are (un)like similarly sized stories. However! Hemming and hawing over close point stories irks me, eps. when the story could have been half way done by the time the team negotiates the points. If points are slowing your team down or not aiding discussions about sizing, then your team should change how it operates; the process should be helping. We've changed ours method to 1, 2, or 3 (definitions what those mean to our team in another comment I left here). Pointing for us typically takes under 20 seconds. Everyone agrees? Good; done. Disagreements? Either round up or discuss it and move on. The end goal is to help the team create as small of stories that are still delivering value to the org. If any of your agile/scrum ceremonies are not adding value, the retro is a good place to discuss how to improve (or remove) processes so that the team can effectively and visibly make progress.