When you discover that some functionality is missing or incomplete, it's time for a conversation. The team, including the Product Owner/Customer must get together to determine what to do next. Again, spend some time to use the process of breaking that functionality up into thin slices. This discussion can occur at any time and doesn't have to be restricted to specific meetings like Scrum's backlog grooming or sprint planning. It can be held anytime that the team is able to have the discussion.
If the discovered functionality is important enough, the business people will ask that the stories are moved forward to be completed sooner. The trade-off is that other stories are pushed back and will be completed later. By having paper thin stories and a measure of the number of stories the team is completing over some period of time, it's much easier for the business people to make these decisions.
For example, the conversation may go something like this:
Developer 1: We aren't validating that the Customer has the available credit for the total amount on the order. Is that something the system should have?
Product Owner: Yeah, absolutely!
Developer 2: OK, do we need it in this release or can it be deferred?
Product Owner: I really think that's something our people in the field need to have in this release. We're trying to reduce their manual workload, and without the automatic check they would have to call in. That kind of defeats the purpose, doesn't it?
Developer 1: Fair enough. Let's break this up into stories and see what we have.
(A short time later.)
Product Owner: So we have 5 stories that will deliver the automated credit check.
Tester: These include the real-time checks against the back-end accounting system. What if we had a local table that's updated from the back-end once a day. Would that be good enough for the first release?
Product Owner: Well, the way we work right now allows us to book an order if it crosses the credit limit. Once the limit is crossed, though, we don't allow more orders. So, I think something that's updated once a day would be fine.
Developer 2: Cool... that means we could defer 3 of these stories for the real-time check, but we'd have to add another for the local credit data source.
Business Analyst: What about privacy? Is it OK for this system to contain that credit data?
Product Owner: Hmmm... good point. I'm not sure. I'd have to check with the Information Security group. You know what? When I look at the backlog for this release, there are plenty of "nice to have" stories at the bottom. We can drop 5 of them and go ahead with the real-time check.
Others: OK. Ship it!
Note as well that it may also be the case that the business people may decide to delay the release until all those stories are ready to be shipped. Also, you should note the collaborative nature of this conversation. While the specifics of the example conversation are somewhat contrived, I've been present with many teams that have worked this way. This approach is far superior to having the Product Owner go away and return at some point later with a handful of stories. Story writing is a team sport!Product Owner: Yeah, absolutely!
Developer 2: OK, do we need it in this release or can it be deferred?
Product Owner: I really think that's something our people in the field need to have in this release. We're trying to reduce their manual workload, and without the automatic check they would have to call in. That kind of defeats the purpose, doesn't it?
Developer 1: Fair enough. Let's break this up into stories and see what we have.
(A short time later.)
Product Owner: So we have 5 stories that will deliver the automated credit check.
Tester: These include the real-time checks against the back-end accounting system. What if we had a local table that's updated from the back-end once a day. Would that be good enough for the first release?
Product Owner: Well, the way we work right now allows us to book an order if it crosses the credit limit. Once the limit is crossed, though, we don't allow more orders. So, I think something that's updated once a day would be fine.
Developer 2: Cool... that means we could defer 3 of these stories for the real-time check, but we'd have to add another for the local credit data source.
Business Analyst: What about privacy? Is it OK for this system to contain that credit data?
Product Owner: Hmmm... good point. I'm not sure. I'd have to check with the Information Security group. You know what? When I look at the backlog for this release, there are plenty of "nice to have" stories at the bottom. We can drop 5 of them and go ahead with the real-time check.
Others: OK. Ship it!
In any case, using this approach enables these sorts of business decisions. This is the primary reason to work in such small slices, and was the whole intent of the Story approach from Extreme Programming in the 1990's.
After all, the ability to adjust to and accommodate these changes is part of the definition of agility.
Comments
Alan