Anatomy of a User story

Here is a sample product backlog (wish list of features) for developing an online course 

  1. The instructor should be able to deliver classes online on a 1 to 1 or 1 to many basis
  2. Online assessments and evaluation
  3. Discussion board
  4. Online payment facility

With this much information it becomes very difficult to estimate it, or to develop it. As a developer these are the questions coming to my mind immediately about the item No.1 which is ‘The Instructor should be able to deliver classes on a 1 to 1 or 1 to many basis’;

Clarifications required;

  1. Are they live classes or record and play or is it live classes with a facility to record and play.
  2. Can I use third party tools, or should it be developed from ground zero
  3. Can I use open source components
  4. Can it be just a slide show with voice, or should it be slideshow and instructor video side by side in a automatically synchronized fashion.
  5. When there is bandwidth crunch, can I switch off the video
  6. Should there be options for streaming high resolution, low resolution
  7. Paid streaming Vs free streaming (ad free, faster, offline viewing)
  8. For 1 to many, how many concurrent viewers
  9. Pass word protection
  10. Sharing option
  11. Renting option
  12. What is the acceptance criteria

This list can be quite a lot, and as an engineer I need clarity on these, else I will not be able to estimate the work involved. These are the first cut of clarifications required. During development I may have more functional / technical questions.

A user story essentially has,

  • The product backlog reference.
  • The description of the feature to be developed in detail, in a non technical language.
  • The conversations section captures the questions and answers that arises during the sprint planning meeting and throughout the development process.
  • Acceptance criteria – This section provides the acceptance tests, which will be run during the sprint review. These are defined upfront and documented, so that the engineer can proactively work to on the code, to ensure acceptance.

It is quite possible that a feature is accomplished with the help of multiple user stories. There can be a 1 to many kind of a relationship between the feature and the user stories. A user story must be something which can be declared as done, 1 to 3 days time. Larger user stories in smaller sprints reduces the benefits of ‘fail fast is success’ mantra of agile.

Writing the user stories upfront may appear to be a herculean task for the product owner. Here lies the great opportunity to include the development team also into story prioritization and development by conducting story writing workshops. This has the added benefit of functional knowledge transfer to the team in advance. I am yet to see projects where the entire user stories are written prior to the start of development. Here lies the benefits of Value stream mapping, release planning and sprint themes.

In engineering, what you get is what you ask. Investing time and energy to develop clear cut user stories is key to success in the agile world. The value of well documented user stories to ensure conformance to requirements is even higher. It acts as a medium of communication about the functionality across stakeholders. That is a good investment one can make to ensure success of your product.

Contact me 

About Aby 


First break all the rules #Scrum Master

First break all the rules by Marcus Buckingham is one book which transformed me and thousands of managers worldwide into effective leaders ( servant leader)  by providing those 12 great questions, as a road map.. Introduction to the concepts of this research based book, which is written after interviewing more than 30,000 managers worldwide, gave me an actionable road map to transform my managerial style from autocratic to servant leadership.  I recommend this book to all managers, especially those who work as Scrum Masters, would be scrum masters. Movement from the traditional managerial  style of ‘leading from the front’ to the ‘leading from behind’ style that is required to be effective in self organizing teams, could be tricky and painful, till we understand the true spirit of servant leadership. That is where this book helps.  Life is easy, once you master the style which worked for great managers worldwide. Once you master that style, you can manage any good team in this world effectively and with much lesser effort. Get a copy for yourself as a reference book and try to score high on those 12 questions from your team. Once you start scoring between 3-5, see the difference you have made to the team and to yourself. Trust, this helps.

Application of ‘Theory U’ in agile transitions

Right now I am in the middle of a consulting assignment of transitioning a large team from ‘scrum but’ to right scrum. When I say right scrum, I refer to the scrum guide by Ken Schwaber and Jeff Sutherland which can be downloaded from

This team from a very large multi national product company came with the baggage of ‘I know scrum, and now you teach me scrum’ attitude, because they have been practising some sort of scrum. This attitude is not something new for me, as I have come across similar situations before as well.

Since agile is value based, like religions, a loss in faith is very difficult to be restored. No amount of talking would have convinced them. This is the biggest risk/challenge while dealing with teams with partial knowledge of s rum. At least that  is my judgment, based on my past experiences with teams with partial knowledge of scrum.

As a coincidence, this was the time I came across the theory ‘U’ which was advocating the postponement of the three fears of;

Fear of judgment
Fear of cynicism
Fear of change

for effective change management.

I decided to implement the concept of ‘postponement of these fears’ at every stakeholder level, me being the first one. All the coaching sessions started with the request to postpone these fears till the completion of the first sprint, and the results are very positive. After experiencing the right scrum, most of these fears are automatically addressed. So, make it explicit to postpone the fears of judgment, cynicism and change before implementing will give you a smooth start.

Are your stories ready CXO?

What is it that you really want?, and when will you say that it is done?. These are two fundamental prerequisites before delegating work to someone and this becomes the real cornerstone for success in the outsourcing world. Identifying the right features and having clarity on them is the foundation for delivering value to your business and to get the best out of your outsourcing partner quickly, thus maximising the ROI. Agile frameworks, especially the product backlog, user stories, value stream mapping and release planning are great opportunities for maximising the ROI and to ensure the alignment of your IT strategy to the organizational strategy. Agile frameworks provide great opportunities to the CXOs and their business analysts to maximise value, if they embrace agility before identifying the vendors, so that agility can be enforced from the contracting stage itself. Are you listening?.

Posted from WordPress for Android

Three questions to analyse the agility of the teams

Many claim that they have implemented agile, and very few have good implementations of agile. In order to understand the type of implementation one has, these three questions to help;

  • What is the velocity of the last sprint?
  • Do you have work allocation or work volunteering?
  • Can I see your sprint burn down chart?

What is the velocity of the last sprint?

Velocity is the productivity figure of the previous sprint, generally counted in story points. In order to calculate the story points, one need to have user stories, planning meeting and planning poker in place. In a sprint, the team is supposed to commit to the velocity (story points achieved in the previous sprint). The team may achieve slightly more, if their capability is better, and that becomes the basis for estimate for the next sprint. This is the continuous productivity improvement mechanism. If the team members do not know the velocity of the previous sprint, then I must say that it is a serious symptom of faking agility.

Do you have work allocation or work volunteering?

Agile teams are self organizing. The team has to decide how they are going to do the work. In true agile teams, it has to be work volunteering, not work allocation.

If the team has velocity calculations in place, and is thriving on work volunteering, then I respect their agility. They are doing things correctly, where as others are just claiming that they are agile.

Can I see the sprint burn down chart?

A burn down chart is more like a flight landing within the runway. Without it there is no transparency into the process and inspection based on empiricism is lacking. If the team is using the burn down chart to track their progress every day and make decisions based on it, that is a great positive sign of a good implementation.

If a team is doing very positively on the above three questions, then they have a respectable agile implementation. Others are just talking about it.

About the author of this post

Abrachan Pudussery (Aby) is a freelance agile coach, working closely with teams in improving their agility. He lives in Kochi and Bangalore cities of India. Phone 0091 9895372115 email : 

10 key reasons to be truly agile – by an Agile coach, witness

  1. Faster return on investment (ROI) to the customer through iterative and incremental deliveries, than the traditional big bang deliveries. This gives an opportunity to the customers to start using the key features early.
  2. Better transparency to the customer – The customer gets absolute visibility into the development process. In account where we were associated with agile roll out, their customer was asking their supplier (my customer) to recruit more people, because of the better transparency into the manpower loading pattern and the work to be completed.
  3. Better risk management (financial, technical, people) –  The risks could be both positive and negative.  In one large team I got associated with, they built a product for three years to realize that nobody wanted it. A fast failure would have helped them to save millions. That was the reason why they embraced agile. A fast failure of a sprint due to architectural issues will always help to avoid lot of rework. Early sprint failures due to technical deficit of the team stops the development of a substandard product. Is it not good. If you appreciate it, you have the right agile mindset.
  4. Better predictability – In agile planning, the target set for a sprint is always based on the historical data of the team’s productivity. This increases the probability of the teams delivering what is committed, and very often little more than committed.
  5. Better transparency to the development team – In one organization the development head was highly skeptical about scrum initially, because he felt he is going to loose visibility into the development process. Luckily he sat through the agile training along with the team and towards the end he became the biggest supporter for agile. After understanding the agile framework, he realized that the transparency is much better than the traditional models.
  6. Better productivity by eliminating non contributing members– Yes, I meant productivity. Not from day one. If we go to the gym, first we get body pain, then only the benefits follow. Same is the case here. When we embrace agility, initially it hurts, especially the non contributing members to the deliverable. They can either become contributing members, or they do not have a role in the agile world. That is a reality one has to face. Over a period of time (not years, I am talking about a couple of months), you will have a team of contributing members only.
  7. Better productivity through positive peer pressure – One of the key aspects of agile teams is their self organizing nature. The decides how they are going to operate. It thrives on work volunteering than allocation. This brings in better ownership and productivity.
  8. Better work life balance – Agile talks about 8 hour working days. We are not talking about spending 8 hours in the office. We are talking about doing 8 hours productive work in the office within 8 – 9 office hours. This leads to better motivation and energy levels.
  9. Sense of urgency – Every sprint end is more like a project end. The pressure is always on the team. This speeds up work. When we conducted a survey for a team of 100, after experiencing scrum for almost 10 months, they unanimously said that they are under pressure with pleasure. It is a constant self imposed pressure, not the last minute pressures.
  10. Ability to enjoy work – When did you miss your office last, when you took a leave?. Is this an Utopian question?. On many occasions, the agile team members call their colleagues to find out the status and to know about what happened in the daily stand ups and the burn downs. Many occasions I have seen scrum masters reminding their team members to have lunch breaks. These are happening again and again. I am witness to it.

This post is motivated by my past one decades agile training and coaching experience. There are many cases where teams tried to be agile and then failed due to several reasons, which I will discuss sometime later. The term ‘ teams truly agile’ is significant while reading this post. 

Agile transition, team level, our recommendation

Here is what worked for us in the past to transition a new team  into a confident, self sustaining agile team.

T1 – The process starts with a one or two days (depending on the number of participants) workshop titled ‘Agile project management using Scrum’.

C1 – The coach works along with the team during the 1st sprint planning meeting

C2 – The coach works along with the team during the day#1 of the sprint

C3 – The coach works along with the team during the sprint review and the sprint retrospective

C4 – The coach works along with the team during the sprint planning meeting of the second sprint


The whole process gets over during the course of the sprint (as per the sprint duration)

The coach will be available to the team for any doubt clarification (online) up to three months after the completion date of this assignment.

Let us start a dialogue. Call 0091 9895372115  email: