When the company for which I worked around 2005 executed a complete transformation from what is referred to as “Waterfall” to “Agile” software delivery, I experienced my own transformation. As part of the organization’s transformation, they began “Brown Bag User Story Refinement” — a day of the week during the lunch hour when a Product Owner would present their current backlog for review by anyone who wanted to attend. I had a lot to learn, so participated faithfully. I felt a bit uncomfortable for the Product Owners presenting, but quickly picked up on the value of committing to specific constraints in the development of User Stories. Estimation of effort was a breeze for well-written user stories; while others were far more challenging to estimate. Then began an experience which was common on every team of which I was a member (I suspect your experience has been similar).

Retrospective day comes, and as part of review of the past iteration the state of the committed user stories is discussed. There is usually at least one user story (often more) which failed to be delivered by the end of the iteration. In order to identify opportunities for improvement, the team is asked what they believe to be the root cause. In nearly every case, someone on the team notes the “size” of the user story — either the effort required was greater than the team realized, or omissions and ambiguities were discovered which delayed their effort. The Product Owner accepts the criticism and, I assumed, endeavored to improve — but this rarely resulted in significant change. Then, it happened…

I was hired at a startup company to help implement automation (in particular, all things “testing”) and manage manual testing efforts. While in that role, I often identified unnecessary process-based impediments and offered simple solutions to address them. During one retrospective in particular, questions concerning a particular user story were raised, and someone spoke the words I already anticipated: “The user story was too big.” At that, the Product Owner did something which launched me into a journey to discover an effective solution to this issue: they pushed their laptop back, grabbed their pen, flipped to a blank sheet in their yellow pad and asked, “What could I have done to ensure this user story was the right size?”

That question took me off-guard, as it did every engineer in the room. We just stared at that table and each other, speechless. Nobody had ever asked that of the engineers before. Shouldn’t he be asking an experienced Product Owner? Then again, who better to inform the Product Owner in this regard than those who needed the quality of the user story to be improved? He had us! We didn’t really have an answer for that question.

This exposed our the-story-was-too-big response for what it really was — an excuse. This embarrassed me, and led me to ensure that next time I would have a concrete answer to that question. On further reflection, I also realized we engineers were committing to work described, without first applying some ‘Definition of Ready’ to ensure the user story described could reasonably be completed within an iteration. With a well-defined ‘Definition of Ready’, we would have been empowered and enabled to say, “We’re sorry, but it is infeasible for us to deliver the described work within one iteration, so it will need to stay in the backlog until we can feasibly commit to it.” It was our own fault the work failed to be delivered, not that of the Product Owner.

I now coach teams to do the following, which results in significant improvement:
– Collaboratively develop a ‘Definition of a User Story Ready for Commitment’, and follow through. During planning, ensure each user story meets that definition before committing, and ensure the definition is clear enough for a Product Owner to know what needs to be done to meet that definition. One of the most important requirements is (in my experience) for every user story to include a description of “who cares” the change gets implemented (As a [role] ); what the change is (I want [feature] ); and the value to the person who cares (So [anticipated value] ).
– Regardless of how your team estimates effort, agree on the maximum size of any user story you will consider committing to for an iteration, and follow through. Determine to firmly refuse/resist committing to any user story, regardless the urgency, for which the team has estimated the effort to be greater than that size.

This was just the beginning of my journey on this topic. Since then, I have developed an approach to User Story Refinement by which a team has nearly everything they could possibly need in order to deliver the requested work using the most pursued Agile principles, practices and patterns.

Reconciliation to this approach requires an engineer to first, take personal (or team) responsibility for committing to user stories proven to be “too big”; second, define well for Product Owners their expectation of the user story descriptions before they are considered for commitment; third, be determined in resisting/refusing committal to any user story with estimated effort beyond the maximum. The amazing consequences of such a reconciliation are priceless. Pay the price now; enjoy the payoff throughout the remainder of your career.

Be reconciled!