CODIFY as it pertains to a user story

CODIFY as it pertains to a user story
9/9/2014 8:56:03 PM

While discussing a user story this morning, questions like "what might the database look like", brought up the word codify from the product owner.  He quickly said "…ah...good point.  Let me quickly codify this."  and more detail was added to the user story to remove any doubt.  This zeal for adding detail to a story is wonderful.  This does take more time.  And it does walk on the fine line of the product owner specifying the solution rather than the requirements.  But as long as the team is working to define this – not just one team member – all should be ok.

This topic makes me want to quickly discuss what in my mind What makes a good user story?

I think we all know that a good story is usually defined similar to this:

As a <user type>, I want to <function> so that <benefit>.

But this often times leaves so much unsaid from the perspective of what was agreed on when we sized this story.  Did we agree to have a horizontally scaling database.  Did we agree to a caching layer?  Was that a direct write to the database in the run time call to the web server?  Or was that a pass off to a queue to be handled by a back in system?

The more factual evidence you can gather during your sprint planning the better.  Ask as many questions as you can prior to estimating (in points I hope) on the card and then pulling it into the sprint.  The more you can say you are or aren’t doing the better for all involved.

While the short three part sentence is the basis for a good story.  There is no rule in place to keep you from adding notes along the way.  This may mean a discussion around data structures, infrastructural needs, performance requirements, etc.  In our case we are building a rather large REST API that another part of the clients company will be consuming.  So in that case we also define what the end points will look like and what they might return.

Negative statements are sometimes more powerful than the positives.  What are we agreeing to not deliver.  We may put in there that we will build a system that has an eye on scalability, the right hooks are in place, but scale can’t just be turned on at the end of this sprint.  Some call this technical debt.  Some call it work not yet finished.  In this case – it is a plan to add a feature at a later date.  Hitting scope is sometimes more important.  And in that case we need to call out the things that we are not delivering as part of delivering more features.

We also like to clearly call out what done means as it pertains to this story.  This might be a list of bullet points.  It might be a test case.  But at the end of the sprint – it is very clear what is being delivered and how well what is delivered conforms to what we committed our team too.

comments powered by Disqus