It’s a constant problem. User Stories are defined by the Product Manager, defining apparently bare minimum functionality, and the estimate given by the Scrum team for the task is way beyond a couple of days, in some extreme cases, going even beyond a Sprint cycle. And the Product Owner is told regularly by the Scrum Master and others that the work needs to be broken down into smaller tasks, not going beyond a couple of days. In such cases, this issue can be a source of frustration for the team, and particularly for the Product Owners. I have heard Product Owners get frustrated to the extent of “I cannot break this down any further, why don’t you?” and similar versions. But such frustration, even though seemingly valid, is not a solution. What is a solution ?
Well, let’s be honest. A post such as this cannot be a panacea, it can just hopefully provide some help, some more thinking about how to try and breakdown tasks into smaller parts that can be fit into a couple of days of effort and hence much better tracking and accuracy of effort estimation as part of Sprint planning. Of course it is not easy, else there would not be much need to write about it (or where so many people would have written about this topic).
So what can be done in such a situation ? How do you try to break up seemingly impossible tasks into smaller tasks ? Well, first, I would not try to write absolutes, that every task can be indeed broken down into smaller tasks of a couple of days. We have seen tasks which relate to architecture or design work, or work relating to database work where the work was much larger than a couple of days. But there is a lot of user centered work that can be broken down into smaller tasks.
For example, consider somebody preparing a tool where users enter their password twice. This is typically used for registration cases where the password is entered by the user, and where it is critical that the password is not a mistake entered by the user (and where the system will not inform the user about the password in any way, a fresh password would need to be generated in case the user forgot the password). In such a case, the system would have multiple validations; a path where the system accepts that the password is correct; in another case where the 2nd password is blank, or incorrect, or does not contain the required number of special characters or numbers or upper case characters. In a number of cases, the validation for correct or incorrect are part of the same task that the Scrum team has to provide estimates for.
One way to break the tasks down is to separate the tasks for the positive and negative validation into separate tasks that need to be estimated separately. This ensures that the discrete tasks that need to be estimated separately are hence of smaller estimates, and in fact, the scheduling of the tasks can be done separately, even in different Sprint cycles. In extreme cases, some of the validations that needed to be done could be discarded if it is felt that the priority of these items is much lower than other similar items.
And of course, this is not restricted only to the Daily Scrum meeting, but other meetings as well where interaction between teams located globally is required. A Daily Scrum is supposed to be a quick meeting, where the attendees of the meeting quickly lay down what has happened since the previous meeting, what will happen till the next meeting, and some of the problems that they are facing. At the same time, the Daily Scrum meeting is not a meeting where people try to discuss the solution of these problems – those problems are supposed to be reviewed and discussed in follow up meetings where the relevant people get together and try to figure out solutions. But the idea of discussing the problems in the Daily Scrum meeting is to ensure that everybody knows the problems that are occurring, with the expectation that a full attempt will be made to resolve these problems before the next meeting.
In many cases (and true for many companies, especially the larger ones), the members of a team are spread geographically. Companies have learnt that they have to take talent where they can find it, and in many cases, talent is not willing to re-locate to be with the rest of the team. In other cases, mergers and acquisitions results in teams being added from different locations, or with resource adjustments, projects can be assigned to teams across locations. In all such cases, getting teams to work closely together is important. For the Daily Scrum meeting, things are even more comfortable when the team dynamics is relaxed and friendly. When team members are located in different locations, getting face to face is critical on a regular basis. However, depending on the distance, springing up travel money for regular meetings face to face is difficult.
Video conferencing poses a solution to this problem. When you can see somebody on the video screen and hear them, it makes for better interactions. It can sometimes have some amount of inertia in setting up the video conferencing, especially for people who are working from home. However, the equipment to setup video conferencing is now fairly cheap and can run from almost anywhere which has a workable internet connection. The advantages far outweigh any possible problems that may be faced. It has been my experience that once you have interacted with people face to face, there is an additional amount of trust as well as the ability to ask tough questions without getting a pushback (this is an interesting experience – when you only know somebody as a voice from another side, and have to ask tough questions during any kind of meeting, pushback is less when you have been regularly interacting face to face).
When you are located in a location where there is a chance to meet up with other team members, not located very far away, then it makes sense to visit on a regular basis, for the same reasons as outlined above. There is a certain amount of inconvenience in making such trips, but there are advantages for this as well. If you are the Manager of such remote people or the Scrum Master, then do make an effort to try to encourage your team members to opt for video conferencing and visits.
The title of this post is a bit broad and could be thought to be confusing. So let me clarify this a bit. People who use Scrum as their development model know a lot about user stories capturing their requirements, but when you get into more detail about how to define user stories, the way that different teams provide details vary tremendously. There are some teams that opt for clear and concise user stories, short and to the point; there are other teams that provide some voluminous details to the user stories, these being quite wordy. Some would think that these stories are overkill, and such details are not required. I am not getting into this debate directly, somewhat in a more oblique way.
My belief is that the User Story should provide details of what is needed to be done, and teams need to take the call about why the User Story needs to be done in a specific way. For example, the Product Manager could come out with a specific requirement that a piece of functionality needs to be using a specific third-party component. So it could be: As a user, I would like my the Zip Code validation to be done in the second screen shown to the user, using component. Now, you would not expect the Product Owner to define a specific component to be used, since that is more in the technical realm.
If you were to proceed a few months down the line, with some attrition happening in the team (or the Product Owner getting busy), the Scrum team members who were working on the User Story as part of their Scrum tasks for the month might not be clear about why this specific component was to be used. They know that other teams already use an existing component, which has slightly better functionality or is faster, and it might make more sense to disregard that part from the Product Owner about the specific component to use. However, there is a specific point that was not known to the engineer who was working on this User Story. The organization was going to strike a deal with the makers of the third-party component which would drastically lower the price of the component, which was the reason that the Product Owner had specified this earlier.
If this detail was captured in some way during the creation of the User story (say by adding a small point, or small detail) in the tool capturing the User stories, it would present clear details to the Scrum team worker that it is not negotiable to take some other component even if it is slightly better, and there would not be any confusion about this. At the minimum, the engineer could re-confirm with the Product Owner regarding the component to use, since the engineer would have understood the need about using this component specifically.
This gets even more problematic when rotation of team members off the team or attrition means that the person who had initially discussed this with the Product Owner is no longer responsible for this User story, and there would be some confusion on behalf of the new engineer in terms of actually doing the work on this User story. It is not just in the case of components where this is valid, it would be valid in numerous other situations as well; and it is for individual teams to decide about the amount of details they add in the User story.
It has been the experience of many teams that the process of writing User Stories is mostly a one-person effort, or rather, a one-role effort. The Product Owner is the one who is expected to write the User Story (or rather, all the User Stories). If there are multiple Product Owners, then they would be expected to distribute the User Stories between them and deliver the same to the team. This has been the expectation of many teams as well – my discussion with many team members is that they expect that the Product Owner will have the entire responsibility of the User Stories. Talking about sharing the responsibility of the User Stories between the Product Owner and the Scrum team does not really draw any enthusiasm within the team. The common feedback from the team is that they do the implementation work, while the work of defining the requirements needs to be done by the Product Owner.
However, it is important that this be something that is discussed well within the team and with the Product Owner, since the User story is a critical document that forms the basis for all further work done by the team. It cannot be just a document made solely by the Product Owner. Instead, the document should be the outcome of discussions between the Product Owner and the team; these need to happen at a regular basis. A draft of the User Story can form the basis for this discussion, and as and when the discussion happens, the User story can be revised to incorporate the outcome of these discussions. The team needs to be an active participant in this activity, and with their previous experience about the details of the product and technical knowledge of feasibility, it is critical that the team works to help refine the User Story (for example, defining the workflow of a feature may be far easier one way rather than the other).
What is the advantage of doing something like this ? For one, it ensures that the User Story is something that is more realistic about what is possible and what is not feasible (else, it could be something like the team not sure about the User Story that is delivered by the Product Owner, which has its own cost). Further, making sure that the team is involved in such a way ensures that the team gets a sense of shared responsibility of the User Story, which increases their sense of overall responsibility for the Scrum effort; something that in most cases helps the chance of overall success of the Scrum project. (This sense of responsibility is of critical importance, with teams doing this as a formality not really reaping the advantages of the team that really feel responsible for the project).
At the same time, this is not easy to do. Teams will feel that additional responsibility is being dumped on them, and it needs an intensive discussion to ensure that the message has sunk home and is understood. One cannot force this on the team.