Although aging makes beef more tasty and delicious, user stories that have been discussed but not implemented for weeks can easily become uninteresting, boring or even hated by developers. This happened in our team two times in the last months: the developers started to work on a low priority, not discussed story instead of doing the high priority, well discussed one – that was standing in a backlog for a couple of weeks.

The efficiency of software development depends on many different factors, but I’m pretty sure that the enthusiasm of the developers in the team is one of the most important ones. You can have the best team, the best product owner and any super process, if the team does not like (or  is not inspired by) the product it develops, you won’t fly.

We usually work with small teams and we like discussing a lot about the user stories (some say, even too much). The discussion is obviously good for understanding the requirements, discovering contradictions or misunderstandings, but it also tunes up the people to implement it. I have already seen cases, where one of the developers started doing the first steps of the implementation right after the discussion, in the breaks or even during the meeting itself. (SpecFlow has been started this way, for example.) And an eager developer can be very productive!

But if the story gets into a backlog after the discussion, and for some reason you cannot start working on it, developers will start seeing it as uninteresting or as an obstacle. They will find a way to somehow escape from these stories or if they will finally work on them (because the PO forces them to do so), their efficiency will be poor.

Here are my ideas to make such situations better…

For product owners

• schedule user story discussions in a way that the team can start working on it shortly after the discussion (organize more, but shorter discussion meetings, if necessary)
• leave time for the team to discuss the stories and let them discover the requirements through the discussion
• if the story has to wait, keep up the interest. e.g. you can discuss other feature ideas that can be built on the waiting story
• try to avoid forcing the team to do the particular stories: make them to pick it by themselves
• allow the team to make small prototypes of the features (this is always good), even if there is no time yet for the full implementation
• ensure that the infrastructure supports making small prototypes efficiently (feature branches, feature builds, place to share prototype results, etc.)

For developers

• make good discussions about stories – you are here not only to understand the requirements, but also to make them even better
• if you feel eager to implement the story, but don’t have the time, you can also do a time-boxed prototype
• use your tools efficiently for prototyping (e.g. use feature branches, private builds, etc.)
• if you have to work on a story that looks uninteresting, get a colleague or two and discuss it over (at the coffee machine, for instance) – the discussion will warm you up and you will feel much better doing the implementation