Using Retrospective Meeting For User Story grading

We have all heard or asked this question at least once if not more

“How do we write better user stories”.

How do we put ‘in words’ what we want to be built. Both the Technical team and the Business team try to get their heads around this one.

What does a better user story mean? When people sayA better user story’ in most cases they mean that the it should be clearly defined with very clear acceptance criteria or Definition of Done. Think “How can the developer know that the story is Done”. If the developer does not know when the story is done then it will never get done.

The problem in writing better user stories- User Stories are written by people and people vary in their analysis, probing, breadth of knowledge and the way they articulate a need. We can draw guidelines for some completeness and uniformity but it is up to the folks who write and what tools and processes they have to get feedback, reflect and correct and better.

There should be a simple way in which bad or less complete user stories are identified, Analyzed and Communicated

The Retrospective Meeting – I recommend using the retrospective meeting to be the starting point. Start by rating the user stories in the Sprint for its completeness and clarity. This is done from the Scrum Team perspective once the delivery is done. Give a 1 to 5 rating and pass that feedback on to the Product owner or Product Analyst who is involved in writing the user story.

This process will be very effective as over time you will have a very clear understanding on what and how you can create a user story that captures the complete essence of a need and also make it complete enough for developers to deliver.

This is also important for developers because in many cases user story is not just an activity done by someone in silo, there are sessions where the technical team asks questions and gets answers. Once you start rating your user stories after delivery you also find other bottle necks that influence the completeness of the user stories.

How I became a Scrum Master

The best way to start this Blog is by telling you how I got here. I have several years’ experience working in the Hi-Tech space across three continents and 4 countries. It is nothing great looking at how traveled the general Tech Public is now a days. Before I got into Software Delivery I had a stint in Software Services Sales, Professional services, People Management and Product Marketing. I ended up at the Software delivery side of things via a Content Management route.

Around 10 years back I became fascinated with Content Management starting with my love for blogging. I started with delivering open CMS solutions and progressed to enterprise CMS solutions using Documentum Web Publisher and Adobe Experience Manager. Somewhere in between I landed on a Scrum Master role. It was more of a PM role that ran on Sprints. It is true that before this I had some knowledge of Scrum and had read a bit about Agile Programming as I was transitioning from the front-end customer engagement into a delivery role but nothing enough to be a Scrum Master. Some people say that is a reverse progression Customer Facing to Delivery :). I don’t think so because there is only progression, no reverse or forward progressions.

Wearing a Scrum Master’s Hat with no formal training in Scrum had both its benefits and Challenges. The benefits included that solid foundation learned from really getting hurt bad. The Challenge always the long learning curve and the bruises that came with it. But all went well for me by the time I got myself certified. And that was two years into the game and many decent Sprints.

So for me I was playing the role of a Scrum Master much before I was officially certified as one. May be that is why I always think Certification should be backed with real experience on doing the work, always. I am not saying it has to be in the same order as I had. Since I learned much of it on the job, I went through so much iterations of my own knowledge and skills, that I kind of started having a philosophical connection with the Scrum Model. I started seeing this whole process work for me personally that I started looking at Scrum beyond just the development of software.

Getting Certified was an interesting turn of events, because till then though I was a Scrum Master in my role, I did not really go out and say I was one even in my resume. I continued to call myself a Project Manager. But once I got certified I also started meeting many other people who had certification. To my surprise some of them had nothing to do with Scrum. A point when I felt my Pre-Certification experience added so much value to me as a Fresh Certified Scrum Master, when it comes to acting on the field.

Another turning point in my Scrum career when I did my first training online for a team of 25 people with an average experience of 10+ years and included Project Managers, Delivery Heads, Developers, QA Engineers and so on. A team of 25 who logged in for a 16 hour session across 4 days from many different countries. That is when I figured that my practical experience and learning from my own mistakes coupled with my story telling based Coaching and anecdotes kept a virtual class going well. This told me that it is time to switch into an Agile Coach role, but by always wearing the Scrum Master hat, because every team is different and there is so much learning on the field when you work with different teams.

When you are a Scrum Master for a while people always think what next. Some go the Manager Route, Some go the Coach route and some even go the Product Owner route. But I chose a role of Scrum Master for multiple teams which helps me to be a Scrum Master for some team and a Mentor and coach  for others.

Finally I decided that my career Goal is to bridge that Gap between Certification and Execution and the best way was to start a focused blog, that will help other aspiring Scrum Masters, people interested in getting certification  and also help me in advancing my career. is a blog as well as a place for people to reach me in y professional capacity (other than the poet, writer and podcaster in me). A place where I can add practical tips, questions I have and my ‘thoughts-gone-wild’ from my experience in a ‘Not so Perfect’ world.

Coming to the perfect world, An ideal scenario is good and an understanding of that is needed for a foundation, but we all know that ideal scenarios do not exist everywhere. Every organization and every team and every individual is in a constant state of change in one way or other and you need to be creative in your processes and its practical application in order to build great products without complicating things.

I welcome you all as in the coming days as I share my thoughts more in here.