Get certified - Transform your world of work today

Requirements -- a Hard Nut to Crack?

03/12/2014 by Usha Ramaswamy

Once, when I was conducting an Agile training, a participant asked me, "Which phase of the SDLC do you think is the most challenging?" I replied, "Requirements management." He asked, "Why?" I clarified, "Requirements are constantly changing; they're often unclear. If you don't get the requirements right, it affects all the other phases."

The case is similar with Agile. Within a sprint, if you don't get the user stories right, it affects development, testing, and the outcome of the sprint, and it takes a lot of effort to fix this later. Let me illustrate with an anecdote.

I was coaching teams in an Agile project where the product owner and ScrumMaster belonged to the client organization. The team was facing a problem. The product owner used to create user stories only during the grooming session, and not beforehand. As a result, during the sprint planning meetings, user stories got groomed and the meetings got extended. The requirements also kept changing until late in the sprint. The team spent extra hours reworking to accommodate the changes. Testers got the code of some user stories for testing only two days before the end of the sprint. Developers and testers tried voicing their concerns during retrospectives, but they faced stiff resistance from the product owner. The product owner would rarely attend the daily stand-ups. Here is an idea of what happened:

Day 6 of the sprint (3 days before end of sprint)
Product owner: "Hey, guys, there is a tweak I made in this user story. I realized that the approach we discussed before will not work. We have to go with a slightly different approach. This can't wait for the next sprint because this is very important for the customer. Let me explain . . ."

. . . and the product owner outlines the change needed. The product owner then asks the developers how long it will take to change the code.

Developers: "Well, if we stretch a bit I think we can rework on a couple of classes and have it done by tomorrow."
Product owner: "Good, then let's get on with the changes."
Testers: "But. . . . "
Product owner: "But what?"
Testers: "We won't have enough time to finish testing the changed code. We can take this up as the highest priority in the next sprint."
Product owner: "Well, for one thing, Agile is supposed to adapt to changes, right? So roll up your sleeves, stretch it out, and just do it. You guys do not understand the importance of this from a business perspective!"

The developers and testers feared that the product owner might escalate this as an issue. The ScrumMaster was ignoring these issues. This led to developers and testers agreeing to the changes and stretching sprint after sprint. Code quality was impacted; there were a lot of defects within the sprint, as well as during the later regression cycle.

How did this get resolved? One of the offshore tech leads spoke one-on-one with the product owner. He realized that the product owner was managing two products and didn't have enough bandwidth. The tech lead then had a couple of one-on-one discussions with the ScrumMaster to explain all these impediments. Reality now dawned on the ScrumMaster. He took this up with management; this led to many other discussions. After a couple of months, the product owner started focusing on a single team, and the other team got a new product owner. User stories were in better shape, and major changes got moved to the next sprint. Voila!

Of course, there were other dysfunctions affecting the team, but now that the ScrumMaster and the team realized it, they slowly started working on those other problems as well.

Learning: Get to the root cause and find a simple solution. Sometimes simple communication can bridge gaps and resolve issues. Problems are not punishments -- they are an invitation to a higher level of thinking!