Estimating in a team with knowledge islands
We have been practicing Scrum for some years now. Due to reorganisation our team was rebuild. The new team consists of application managers, developers and content managers. We can not completely dissolve the knowledge islands, since it is e.g. unlikely that the content managers would start to learn programming and vice versa.
We try to do planning poker and sometimes multiple people can estimate. But often it is quite senseless since only one or maximum two team members can really estimate the work to be done.
Is this normal? If not, does somebody have some ideas on how to improve the situation?
Why do you believe it is senseless if the team estimates, but only 1-2 people are likely to work on the story (due to specialization)? To me, there are several benefits to team-based estimation under this scenario:
- It makes visible the obvious impediment of "knowledge islands" within the team. This is a significant vulnerability to the organization. Does important work simply not get done because the experts are unavailable to either estimate it or work on it? The Scrum Master should always shine a light on any practice or situation that doesn't follow Scrum, impedes the team, or is harmful to the company.
- Team-based estimations will help to develop team identity and what they consider a "3" or a "5" estimate, even if team members providing the estimates are unfamiliar with the effort needed. When estimating, there shouldn't need to be a consideration of technical expertise. Stories should be customer-centric, focused on business value (the "what"). In Sprint Planning and the Sprint, the team should then begin discussions on "how" to solve the "what".
- Permitting only a subset of the team to estimate based on their subject-matter expertise only encourages the silos present within the team. Don't do it! Team-based estimations encourage discussion and knowledge-sharing - support those discussions and sharing of ideas whenever possible.
Especially with a new team, these improvements will take quite a while. However, it simply isn't an option to maintain the status-quo when you know it is unhealthy. Good luck!
You say that the team can't completely dissolve the "knowledge islands". To what extent however are they willing to do so? Do they recognize that they are, as Timothy says, vulnerable?
Before the team can find a solution to this, the problem must first be recognized by all team members.
Attempting joint team estimates through Planning Poker can be, as you have found, a good way of shining a light onto this issue.
Thank you all for your ideas. I see your points that the "knowledge islands" are really big impediments.
Maybe I did not explain properly. We actually do planning poker all together. The problem is not that the team estimates and only two people work on it. Let us say, Carol and Dave can and do estimate only that one story. Carol and Dave will be working on that one story. Sometimes the rest of the team would then just not estimate or show "?" because they feel unable to cope.
The team knows that the "knowledge islands" are an impediment. We also try to dissolve them and team members do show interest in other topics. The problem is that content managers just will not be able to do coding or server administration.
The team urgently wishes to be able to estimate about topics they got absolutely no idea of. Now as I mentioned earlier, we do planning poker but it does not seem to help (maybe we are doing something wrong). Maybe you got some other techniques that could help? Or maybe we just need to resolve our "knowledge islands" first to make this work?
Let us say, Carol and Dave can and do estimate only that one story. Carol and Dave will be working on that one story.... The problem is that content managers just will not be able to do coding or server administration.
Sara, the problem seems to be in part the make-up of your stories. Outside of tech debt or bugs, stories should be created around business value, and not rely on technical or subject-matter expertise. It isn't necessary for a content manager to know coding in order to provide a size estimate (and it is their estimate or guess as to the size of the story).
I like to use an analogy of a boulder. The business value is to move it from point A to point B. What might some questions be?
- How far is it from A to B?
- How heavy is the boulder?
- Does it need to be carried, or can it be rolled?
- What is the terrain like (uphill, downhill, uneven, rocky, smooth, etc.)
The team can provide a relative size estimate (relative based on other story estimates!) on this effort, without needing to rely on weightlifter Dave, or Carol who owns construction equipment. Size the story.
There are alternatives to Planning Poker including the Team Sort:
https://dzone.com/articles/agile-estimation-practice
Sometimes it helps to take the numbers out of the estimation picture, at least to start with.