What to do with incomplete stories that depend on customers

Question

We're starting with scrum, user stories, and agile. Some of our tasks require final testing from our customers to verify that they are completed according to their needs, but sometimes they don't complete the testing, or respond, for well over a week (or 3). What is the best way to handle these tasks for QA? Can we close the task as complete after X days? Should we have the sales rep remind them a couple times? We're trying to load our sprints 1 week at a time, would having a larger, month-long project to push these things to be a good option?

Answer 1

Clearly Identify Your Problems

Some of our tasks require final testing from our customers to verify that they are completed according to their needs, but sometimes they don't complete the testing, or respond, for well over a week (or 3).

You actually have four problems here:

1. You have a "definition of done" that is dependent on people outside the Scrum team.
2. Your routine communications don't fit within your defined sprint length.
3. You don't know what to do with incomplete stories.
4. The Scrum team is accepting stories into sprints that can't be completed within a time-boxed iteration.

Possible Solutions

As always, possible solutions must fit both the problems they attempt to solve and your corporate culture, so you'll need to adapt these ideas for your own situation. Your mileage will vary.

1. Move UAT to a Post-Sprint Actvity

Your pain point here is that your team is not allowed to finish a sprint without the input of resources outside of its control. This is a process #fail.

You have a "definition of done" that is dependent on people outside the Scrum team.

If possible, remove user acceptance testing by anyone not actively engaged on the Scrum team from your "definition of done." That doesn't mean no one is allowed to do UAT; you're simply moving it off the critical path for the sprint.

In Scrum, the Sprint Review is generally the opportunity for stakeholders to see the functional increment demonstrated, and to provide feedback. This has zero impact on the success or failure of the sprint; it's simply an opportunity for the organization to reflect on whether they believe the right thing was built, and to provide feedback to the team and the Product Owner about what's important for the next iteration.

In an ideal world, developers and UAT testers are working side-by-side during the sprint so that there are no surprises during the Sprint Review, but in practice this doesn't always happen. As a result, the Sprint Review or a post-sprint UAT cycle by a separate team is the optimal solution.

2. Modify Your Sprint Length

While moving UAT outside your sprint will help with resources and the "definition of done," you also have a fundamental communications problem that includes a lack of respect for the integrity of the sprint or the importance of cadence for the team. This is a process #fail.

Your routine communications don't fit within your defined sprint length.

Moving UAT out of the sprint won't fix your communications problems, or intrinsically improve respect for the team or its process. However, increasing the length of your sprint may provide a number of benefits.

1. It will increase the amount of time available for external resources to perform tasks necessary to meet the "definition of done."
2. It will visibly slow the cadence of the process. Since UAT is the bottleneck anyway, making this issue a visible cost to the project is the proper thing to do.
3. It provides more time for process overhead such as meetings with the UAT team or their managers, thereby providing the Scrum team with opportunities to improve communication with the outside team--at least to the bare minimum necessary to get to "done."

3. Incomplete Stories Return to the Product Backlog

When stories can't meet the "definition of done" by the end of the sprint, then they are simply not-done. In Scrum, stories are either done or not-done, period. Regardless of the reason a story remains undone, it must be returned to the Product Backlog to be re-evaluated. Doing anything else is a process #fail.

You don't know what to do with incomplete stories.

What you're really trying to say is that you have stories that you can't complete because of poor communications or integration with the UAT team, and a process that won't allow you to finish stories without that step. The "definition of done" may be completely reasonable, but the lack of organizational buy-in or resources to meet that goal is what's routinely setting the project back.

By treating your defined sprint length as a firm deadline, you make the problem visible to the organization. Whether your sprint is one week or one month long doesn't matter; the issue is that your process can't sustain the desired development cadence.

Placing the stories back on the Product Backlog forces the stakeholders—or their proxy, the Product Owner—to accept responsibility for the organizational process and the resources available to the team. It is then up to the stakeholders to improve the composition of the team (perhaps by adding a UAT tester or two), modify the organizational process, or take some other action that reflects the value of the project to them.

Note that stakeholders taking no action also accurately reflects the value of the project. Feel free to act accordingly should that happen.

4. Reduce Accepted Stories to Right-Size Capacity

By accepting stories into the sprint that you already know can't be completed due to process issues or organizational roadblocks, you are setting yourself up for a process #fail. Don't do that.

Your team is accepting stories into the sprint that it doesn't expect to complete.

By this time in your Scrum process, you should have a fairly good idea of what your team's real velocity is. Remember, velocity is a measure of capacity, and since you do not have the capacity to complete the volume of work you are accepting into each sprint, you are not using the tools Scrum gives you.

It doesn't matter how much "stuff" the organization wants, or how many stories the Product Owner wishes you'd take on each sprint. The Product Owner sets the priorities, but the development team chooses how much work to accept into each sprint based on the team's capacity.

In your case, some of the capacity is extrinsic to your team. That's okay; it simply means your Sprint Backlog should reflect a realistic capacity for work that can be completed within your constraints.

For example, even if the development team can theoretically do 40 story points in a sprint, but the UAT testers (who are outside the team) can really only be counted on to do one 5-point story per sprint, then your real velocity is five. Let me repeat that: your real velocity is only five (5) story points, because that is the limit of what your team can realistically and sustainably deliver per sprint.

The goal of Scrum isn't to inflate velocity, or sweep process issues under the rug. You should be using the Product Backlog and the team's real velocity to clearly communicate to the larger organization that there are procedural obstacles that are slowing the project down.

If they choose to improve the situation, great! If not, then you've done your professional due diligence by effectively communicating the project's status and constraints, and can leave the responsibility for the project's success squarely where it belongs: with the company's executives and stakeholders.

Answer 2

For successful Agile adoption, quick and close interaction is essential amongst all the stakeholders including dev team, product owner, end-users, and client. If that is not possible then first you need to bring everyone on-board and try to convince them about the advantages of having a quick feedback loop. If that doesn't work then you adapt. Beauty of Agile is that you are not bound to process but you find ways which work better for you and adapt accordingly.

How about removing UAT from the "definition of DONE" of your stories? A sprint can be considered "done" when the Product Owner (who is part of the team) signs-off of all the stories based on the acceptance criteria. Your team should have already completed the testing of each story before Product Owner sign-off phase begins. So you don't have any incomplete stories due to late response from UAT team.

When the UAT team is ready to provide feedback on a sprint, you may plan for a bugfixing sprint. While in the bugfixing sprint if you find empty cycles (because you did excellent work earlier) then you may work on technical debts.

UAT team is usually composed of people outside of the project team and may have other priorities which may not be insync with your sprint planning.

Can we close the task as complete after X days?

This would not be a good approach. All actions should be based on some events. Closing a task, based on just elapsed time, without any cause/effect reason behind it would be bad.

Should we have the sales rep remind them a couple times?

It may help sometimes in getting feedback but your planning would still be a shaky grounds.

would having a larger, month-long project to push these things to be a good option?

May not help either. In a longer sprint there will be more stories to develop. Once you give the sprint for UAT, they may again take couple of weeks to provide feedback, so you get no advantage.

These are some of my thoughts. Lets see what the PMSE community pros have to say on this.

Answer 3

Hire or designate a Product Owner (PO)

Having part of your definition of done owned by people outside your team won't work. Customers have their own priorities and time commitments.

Based on our experience, you need a designated Product Owner (PO) as a full time member of your team to perform this role. Hire a PO or designate a person within the team, who has good communication skills and an aptitude for business requirements, as the PO.

The PO will communicate with the customers, understand the business requirements and help write-up and prioritize stories. The PO will participate in the Sprint Planning meetings, clarify requirements, tweak scope and priorities (on seeing the effort estimates by the team). At the end of the sprint, when the stories are ready for Customer/User Acceptance Testing (UAT), the PO will test and accept them. The PO will demo these stories to the customers and get their feedback separately and without holding up the sprint. If any new requirements come up (or for that matter even if the PO missed or misunderstood some requirements), these all become new stories to be prioritized, among others, for the next sprint.