Jeff had a great webinar hosted by SmartBear last Thursday. If you missed it, here's the link to the archived webinar and the slides. We got hundreds of questions from the audience, and SmartBear sent fifteen of them on, they'll be posting all of them on their site soon, but we thought we'd give you a sample of a couple. If you watched the webinar and want to get the full scope of Jeff's thinking on Scrum, you can sign up for our March or April Scum Master courses that are coming up.
What size team is "too small" for scrum?
Zero is the quick answer. We’ve seen Scrums of three of two and even one person. But for most teams the rule of 7 plus or minus two is the way to go. This usually has enough team members to allow for cross functionality, but not too many to make communication and sharing difficult. The more common problem I see is that teams are too large. If you have a team over 9 people, your team is just too big. And the research shows a team of 5 will go faster than a team of 7.
How do you deal with product ownership and customers on the team with shrink wrap software where there are a wide range of different types of customers with differing needs?
We coach all of our venture company on developing “personas” which are user archetypes for the product. Product Owners should take our Product Owner course to dive into detail on this.
There needs to be one “vision” for a product. Now, there may be different types of customers (personas) that will be buying your product for different needs, but there needs to be one person who is prioritizing all of the differing customers’ needs. Is it more important to implement X feature for a certain type of customer, or Y feature for another?
These can’t be of equal priority. If the product is large enough that you have multiple teams and multiple product owners, there still needs to be a Chief Product Owner who can settle questions of priority among the product owner team. I strongly recommend that even in large projects there is ultimately only one backlog that is organized in priority order. The reason for this is that the whole group should be focused on the top priority items, rather than diffusing their efforts on whatever features they think are important, rather than what the product owner and the customers think is important.
Read the Citrix Online case study to see how to prioritize releases of a portfolio of products at the enterprise level. This is another topic covered in detail in our Product Owner course.
That Product Owner course will be held in Boston on May 31-June 1.
English 
French 
Spanish 
English