Howdy, how was your Christmas? I am sure everyone had a good week spending time with family, unwrapping gifts, singing Christmas carols, and eating cookies. And now its almost time to step into 2015. Another year gone, lot of good times, a few down times, lot of experiences, lots of learning, flew high, went down, rose up again, moved on.. that’s how 2014 was for me. I guess that’s how life is though, isn’t it? We make mistakes, it hurts, we learn, we get smart 😉

So how do we get smart? One of the ways is by doing our homework right. For all that I went through in 2014 – good or bad, I want to sit back, think about it, assimilate all the learning, list the corrections I want to do, lay my goals for 2015, build a plan of action, and may be do some foundational work, so that I can have a smoother sail in 2015. Pretty much – DO MY HOMEWORK RIGHT 🙂

In the world of Agile, we kind of do the same thing. Each time we go into a new sprint / iteration, we have our planning sessions. However, to be well prepared for these planning sessions, to be able to be in a position to build an effective plan, we need do some ground work, some home work – GROOMING. We groom our product backlog, review the stories with the team, see if they are missing any details – from both business and technical perspective, do the research, if need be, to build a better understanding. All this is nothing but homework, to be able to size the stories, task them out, and take them up for development when the time comes.

Software development is all about translating ideas into reality, how do we do such a translation though? The first step is definitely communication, can be written, oral, multi-media, musical, videos, or even skywriting, it really doesn’t matter, if you are able to get your ideas across the table in a crisp and clear fashion.

Now, there are some merits to written communication and there are some to verbal communication as well. Written communication provides a permanent record, is easily share-able with groups and/or remote resources, is generally well thought out and thorough, however, it can be easily misinterpreted. On the other hand, verbal communication, gets us immediate feedback, is dynamic, it adapts and evolves with new developments, can even spark new ideas, makes it easier to reach a common ground, however, it is all up in the air and can be easily lost once we walk out of the room.

What if we combine the benefits of both these types of communication? Doesn’t that sound like a recipe for a WIN WIN situation. User Stories are the written communication that we seek, and the grooming sessions provide us a perfect platform for the verbal communication we need. User Stories are that part of an agile approach that helps shift the focus from writing the requirements to talking about them.

So, What is a User Story? – It is a statement of the value a user will derive from using the functionality (piece of software/application) being addressed in the user story.

And, How does a User Story look like? – It looks like a conversation about the desired functionality. A typical user story card looks something like what you see on the right, but this is just the beginning. A good story will include an acceptance criteria, definition of ready, definition of done, any possible exceptions, relation to other related functionalities, an owner, size, granular tasks, deployment status, a section to capture any discussions and decisions and a lot more.

Who creates the User Story? A business user story, generally comes from the Product Owner or a Business Analyst. And a technical user story, usually comes from the architects and/or any other related personnel.

Who reviews/approves the User Story? The team reviews the user stories. One of the most popularly used criterion to access and review user stories is – INVEST – Independent, Negotiable, Valuable, Estimate-able, Sizable, Testable.

So now that we know a little about the User Stories, allow me to tie the relationship between User Stories and the Grooming Sessions. We have already discussed in the article – The Real World Scrum that in a given sprint we have two grooming sessions – Grooming I and Grooming II. In the first grooming session, all we try to do is access the Definition of Ready (DoR)

What is DoR? – Does the story have everything a team needs to pull the story into the Sprint Backlog? In simple terms, a user story needs to meet some criteria before the team can start the development work for this story. DoR is to ensure that the User Story is well defined – the testers have defined and/or reviewed the acceptance criteria, any risks and dependencies are know and/or met, the team has a fair amount of idea on how they will be implementing the story, and the story has been sized appropriately.

In case a given story does not meet the definition of Ready, the team and the scrum master will push back the user story and will not accept the story for development in the upcoming sprint.

If the story meets DoR, the team then breaks the story down into actionable tasks and estimate them in # of hours.

I personally advise my teams to carry out the tasking effort in between the two grooming sessions. All we do in the second grooming session is, review the task breakdown for the stories, review the task estimates, and address any last minute high priority work items, can be user stories or defects that may have cropped up very recently and will need team’s immediate love and attention.

At this point we have done majority of the work, that we traditionally used to do in our all day planning sessions. All that is left to be done on the day of planning is, Capacity Planning, final review of the sprint backlog (if necessary), and a formal commitment to the product owner.

This is what we call – HOMEWORK WELL DONE !

Happy Reading! 🙂

– Nirbhay Gandhi