Making sprint GREEN

Question

In a sprint (#1) we decided on tasks and user stories. One of the task we thought of 6 hours turns out to be a difficult one, due to technical complexity. The complexity was such that we can't estimate it even in the middle of the sprint. All we knew that we can try to fix it with plan A, if not then plan B, if not then plan C. After each plan execution we retrospect and deviced plan D,E,F. Eventually the commited user story spilled to next sprint (#2).

Now under same user story, in sprint #2, in another task developer notice due to frequent requirement changes the code is NOT in good state. Thus it should be optimized as well. So developer done the optimization under same tasks, which took time obviously and user story spilled to sprint #3.

In sprint #3, there were bugs for the same user story which were fixed timely and sprint #3 went fine.

I do not see any performance problem OR job not done correctly by the developers. But our 2 out of 3 sprints shows 1 user story spilled twice and thus those sprints are red.

Now my questions: Q. What went wrong in managing our sprints? Q. What measures we should have taken to make our first two sprints green? Q. How to handle the alert raised by the developer about the code quality?

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Answer 1

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Absolutely not.

The main (not necessarily sole, depending on who you ask) goal of the Team is to provide value to the customer.

What you describe as 'GREEN', finishing all user stories of a sprint (I assume, based on your question) is a useful indicator for this, but not a valid replacement goal. Consider the situation where you write up a bunch of nice, lovely-looking stories. They are all completed on time with wonderful, quality code. And then you show it to the customer and they ask why you bothered with any of that, because it's all useless.

Did you complete your Sprint's stories? Yes. Did you provide value to your customer? No.

Q. What went wrong in managing our sprints?

You've provided insufficient context to answer that, or indeed even to answer whether or not anything did go significantly wrong. Ask your Team. Bring it up in the Retrospective. But keep in mind that you should avoid leading questions - asking 'What do you guys think caused the Sprint to go wrong?' is not a great question to ask when your Team wasn't thinking it went wrong at all in the first place.

Q. What measures we should have taken to make our first two sprints green?

Evaluate stories more thoroughly before accepting them into the Sprint. If necessary, do spikes (short, exploratory, often throw-away pieces of work) to gain further information on them. Sometimes, though, things will slip through the cracks - and it's not the end of the world.

Q. How to handle the alert raised by the developer about the code quality?

There have been other questions about this topic, both on here and on Programmer's Stack Exchange. Suffice to say, quality is important for later maintenance of code but value cannot be sacrificed completely in order to achieve it. Here's an interesting viewpoint on this topic.

So, to summarize, make sure you're measuring and striving for the right things. Meeting all your user stories every Sprint is a nice metric, but it should not be your main goal. That should always be to bring value to your customers.

Answer 2

Your question is very focused on this story in these three sprints, but you haven't talked about the rest of your processes or context, eg, how much else work was in the sprint, how important the repeatedly failing story was to the customer, how you handle backlog grooming, etc. I think the answer to your question lies in that broader context, so that's the context in which I'll talk about how I might have handled it.

The complexity and uncertainty encountered in the first sprint sounds sufficiently full of unknowns that I would have failed that task out of the sprint & kicked it back to the backlog for further grooming and reprioritization, rather than continuing to spend sprint time & effort on something that was so uncertain. Depending on what else was planned for the sprint, maybe that means the whole sprint would have failed, or maybe it means that we'd complete the other work early and move on.

"Sprint green" is not the only value. "Fail early" is another: because it frees up your resources to regroup and plan before you try again.

Depending on your process, once the story is back in the backlog, maybe it gets some more careful analysis and review as part of the grooming process. EG, if you don't accept stories into sprints unless they are "ready", then the experience in the first sprint demonstrated that you thought it was ready, but actually it wasn't. During that work of getting it ready, there's a good chance you also notice that the code is in bad shape (as was noticed in sprint 2) because you've taken a step back to think about it.

Or, perhaps your process is that you generate an additional story, "Do a spike to figure out a viable approach", which must be completed before the original story is "ready" and thus would be done in a sprint on its own, with the original story done in the subsequent sprint. Or maybe that's a new task on the original story, which obviously increases the scope of the original story, so it can all be done in the same sprint but that reduces the capacity to get other work done in that sprint.

A final caveat: if my customer was telling me "This is the most important story & you must get it done no matter the impact on anything else", then I might have failed the entire sprint immediately, and started a new one that contained only that story, so the whole team could swarm on it.