Is it ok to get only a few team members to join Planning Poker session if new task are added during a sprint?
We are not able to gather into a company lounge as usual due to the virus thing, so it's limited to get all team members to join the planning poker session. Some works in a remote location, and the others are in the office. It's not easy to expect that they are responding to my session invitation, and I want to assign a story point as soon as possible as a product owner wants newly added tasks to be included in a current session.
I am just worried about what a story point made by a few developers is valuable because it's not a consensus from all developers.
Is the story point meaningless or not?
Is the story point meaningless or not?
I'd say it has meaning, given that all team members are accountable for it, regardless of whether they make an individual contribution or not.
Why can't they self-organize a time when all are able to participate?
I'm curious as to why the team can't find a time to collaborate. Of course, with some people in the office (where there may even be further restrictions on the number of people in a room) and some people at remote locations, this collaboration will need to be done virtually rather than face-to-face. It may be harder to do impromptu sessions (especially if roommates, spouses, kids are also at home), but from what I've seen, people are generally expected to be able to maintain something like normal working hours, even if they are home. What, exactly, is preventing the team from scheduling 30-60 minutes from time to time to refine upcoming work and including most, if not all, of the team in this session?
I'd say it has meaning, given that all team members are accountable for it, regardless of whether they make an individual contribution or not.
To expand on this, do the Development Team accept collective accountability for such estimates? If not, under what circumstances would they accept accountability for their estimates?
However it ends up playing out, I’d definitely raise the issue at your next Sprint retrospective. It’s not always possible to get a team to own an issue in the moment — eg, work may be too crazy or the team may not be used to thinking of itself as being self-organizing. But this issue is a great example of why retrospectives are so useful: everyone has a chance to step back and ask, is that how we want to handle planning next time?
For example, suppose you discover during the retrospective that some members of the team thought having the product owner adding work during the Sprint was BS and violates the whole point of using Sprints. What they decide to do next — eg, next time you’ll take a firm stance against adding work to an ongoing Sprint — would be quite different than if the issue is some members of the team feel planning poker is a waste of time or that the problem is that the team is taking on way too much work during each Sprint so they’re too overwhelmed to want to all be involved in planning.