Good User Stories … continued

I was thinking about this and thinking “Well that's not very nice to leave people hanging like that about the 'S' in INVEST and what defines “small”. Especially when I realized I forgot about a psuedo-acronym.

Good User Stories enable the team members and project's stakeholders to INVEST in what is being set as an objective.  Put another way, they communicate functionality that is of value to the end user that promotes further communication when the story is being worked on. And like I said in my last post, 'small' is subjective and because of that the definitive answer is 'well that depends.' Seriously though, in preparation for this post I Googled 'agile INVEST acronym' and it returned 'About 203,000 results'. I Googled 'user stories' and it returned 'About 1,310,000,000 results'. That's how subjective this is. No worries though, it really is a lot simpler than all that. 

If you really wanted to you could probably scan through some of those results and quickly find definitions like 

• anything longer than 2 or 3 or 4 weeks is when it becomes a them or an epic
• small enough to fit within a sprint or iteration and deliver value from it
• the right size is usually about a work week
• shorter than a week is too small 
• a day or two
• and so on and so forth

And you know what …. yup, you got it, they're all correct …. for them! The reality is that when user stories are being written and sized (size 'small'; please :-) ) there are still four more factors. Those factors are time, work effort, risk and overall complexity; I'll save “complex versus complicated” for another post. :-) 

Time is the easy one and because it's easy that's where a lot of people new to Agile stop … and then they have schedule overruns just like they did in the traditional (waterfall) way of doing things. 

Work effort is the first factor (of these four) that starts to ask people to think about who and which roles need to be involved to deliver something of value. After all, if your stories are specific to one person or role you've probably just created broad, high level tasks and labeled them user stories. 

Risk – well this could be a book all on it's own; well what do you know … it is! ;-)   For now, let's just say big risks should equal smaller sizes unless there is a high tolerance for delayed feedback.

Overall complexity as I eluded to above is at least another post and are books all to themselves when you start thinking about complex adaptive systems and other systems theories. For now, let's just say the harder it is to describe the story on a 3x5 card so your intended audience understands what is being asked for the more complex it is.

Oh, that missing pseudo acronym? It's the 3C's – Card, Conversation, Confirmation. Just click on the link for the details in the Agile Alliance Guide.  :-)