Closing stories on time

At a recent internal demo of a project at Srijan, a conversation developed about stories being reopened in projects that followed the Agile methodology. The concern raised by the demo reviewers was that stories must not be reopened. Agile works on the mode of initiating and closing stories defined within defined sprints. So if the project sees a trend of reopening stories, it has serious implications on its schedule and budget.

Let’s look at the issues that lead to stories not being closed ‘fully’. This will help Srijan and other companies on the Agile adoption path to explore how they can ensure that stories get closed and velocity remains high.

For a story to be considered closed, our team needs to have its acceptance based on various criteria:

• Srijan’s QA team lists the actions, functions and results related to a story to consider it completed.
• The client could specify some criteria for the story to be considered completed.
• Theming is a part which is done by Srijan based on designs provided by the client. If a feature is not presented in its right theme during a demo, the story cannot be considered complete. What happens in a demo given to the client at the end of a sprint?

If the client asks for a change that changes the underlying logic of development of the function, we create a new story, and call it a Change Request story. This is then addressed in a separate sprint later on depending on the demo schedule created.

If the client asks for a change that only impacts the display of a function and not the underlying logic, we handle it under a category like Bugs, or as a minor change request, but not necessarily as a new story. It is treated as a story that has to be addressed before the next demo involving that function. So when the next demo happens, the developer has to look at the change request addition/bug which is connected to an old story. So in effect, the story is ‘reopened’.

Theming has huge dependence on an external source in story closure. The theming team needs to have the designs with them well in time to enable a story to be made ready for a demo. If the designs don’t come, theming does not get done. So while a function or a feature is ready for demo, the lack of a theme renders it incomplete. So the story remains incomplete, or needs reopening, depending on how the Project Manager treats it.

So how to close stories on time?

• Get a team and client consensus on how you will treat a change that only impacts the description of a story and not the logic used for its development. Should this be treated as a new story? Should we leave the story open till the change takes place? Should there be an added process/resource to close issues which do not require being part of a sprint?
• Educate the client on the importance of delivering designs in time for theming to happen in parallel to the development. Often the client gets over involved in developing a perfect design and loses focus on when to make it stop, so the feature can get to A/B testing levels. The project manager needs to keep this key aspect in tight control to enable timely story closure. 

Have you faced any other instances that lead to stories being reopened? Are there some other ways in which we can better address these challenges. Would love to hear from you.