In the previous post (Breaking up a large User Story into smaller parts (contd..)), we talked about some of the benefits of ensuring that the User Stories are as small and discrete as possible, such as increased accuracy of estimation, better Velocity, helping the Product Owner do a better prioritization, and numerous other benefits. In this post, we shall look at some of the problems one faces with ensuring that the Product Owner is able to deliver such discrete User Stories without creating turmoil in the team. This post is based on some real-life experiences with different Scrum teams.
The Product Owner has ownership of the user story, although in many teams, practically what this means is that the Product Owner works with the teams to define the User Story, has interactions with the team to refine these, and then finally the User Story is released in a form that can actually be used in a Sprint. Now, what can go wrong in this scenario ?
Well, the number one problem that I have seen is where the Product Owner is highly stressed in terms of multiple responsibilities, or the responsibility is big enough that the number of Product Owners allocated cannot meet the need. In such a situation, the first items that gets affected is time with the team, and also the amount of detail spent in refining the User Story. In most cases, only when the Product Owner spends time with the team on the User stories can there be refinement of the User Story, else you will get bigger User stories and lose the benefits you normally get with the smaller User Stories.
There are cases when the Product Owner knows the requirements, but does not really have the amount of detailed knowledge of the product to slice the functionality / workflow into the smaller pieces that would make up individual User Stories. For example, in a case where a User Entry pulls out some information from the database, the amount of information pulled out would be larger (and include some negative checking cases that you would ideally have wanted to move into a separate User Story).
Then there are the attitude problems. You would want to think that all the Scrum team members are sensitized about cooperation and working with each other, but you do get people who like clear cut roles, and hence within a Scrum team, when there is some amount of cooperation across roles that can happen (as an example, in another successful team, we had one of the testers who had an indepth knowledge of the workflows and provided invaluable advice to the Product Owner which in turn led to the User Stories being as discrete as possible), there can be some amount of resistance. Such attitude issues can lead to the team not being able to reach its full potential, but in many cases, there is nobody really present to investigate and help solve these kind of issues.
Some amount of back and forth between the Product Owner and the team. When a team is composed of engineers, they like to deal with absolute Black and White issues. So, you could have a guideline that the first User story will not have any negative or error cases, but the Product Owner feels that one of the error situations is intrinsic to the first deliverable and hence needs to be part of the User Story. One could argue either way, and that is the same problem that happens in the team, where discussions can become heated, unless somebody is able to ram some good sense into all the team members.
