A Story to Tell

I love to tell the story

About how Toastmasters changed my life.

Sharing my tales and finding my voice

Opened new doors and sharpened my skills.

ToastmastergroupSchwab

I love to tell the story

With style and class.

I thank my fellow Toastmasters

Each and every time I speak.

Advertisements

Confessions of a Scrum Master, Part 3: User Story Happiness & Success

As a user story, I want the respect I deserve so that I don’t develop an inferiority complex.

Oh the user story! You either love it or you hate it. You understand it or you are totally perplexed and frustrated by it. The must fundamental and core element of the Agile process is often misunderstood, under appreciated and misused.

The User Story, child of the Epic and parent to the Task, occasionally suffers from an identity crisis. Last month I happened upon a sad and lonely 8-point story who had only one 0.5 hour task linked to it. It confided in me that it was really a Task masquerading as a User Story but it was too ashamed to tell anyone.

The role and purpose of the user story can sometimes be misunderstood to the point of causing heated conversations and disagreements among Product Owners, Business Analysts and Scrum team members who are new to the Agile process. Here the Scrum Master’s coaching and facilitation of the Agile process is critical to the success and happiness of the team (and the user story).

As a user story, I want to define an incremental unit of work in the “who, what and why” format so that the scrum team can efficiently deliver the requirements by the end of the sprint.

whowhatwhy_userstory

 

As a user story, I want to represent a small piece of business value so that the Product Owner can see the iterative development of the work.

As a user story, I want to describe high-level requirements in such a way that  it sparks conversations among the scrum team members.

As a user story, I want to have detailed acceptance criteria so that the team knows the definition of done and exactly what is expected at the end of the sprint.

As a user story, I want to be groomed and refined on a regular basis so that I will be properly understood, stack ranked and sized by the scrum team.

As a user story, I want to meet the criteria of Bill Wake’s INVEST acronym so that I can be well formed and have high self-esteem.

INVESTuserstory2

Acceptance Criteria of this INVEST story:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Scalable (small sized)
  • Testable

 

As the author of this blog,  I want to share my thoughts and insights about user stories so that you learn in a fun and memorable way!

Confessions of a Scrum Master, Part 2: The Requirements Challenge

Alternate title:  Oh the joys of documenting requirements on a new Agile project!

Many organizations struggle with adopting Agile since it requires such a fundamental and overarching shift in business process.  Often times the biggest challenge with the new process is how to gather and document Requirements.   I’ve observed that a piece meal approach to implementing Agile is not as effective since the performance benefits are not fully realized unless all Scrum team members and stakeholders are on board. So how do we get everyone on board?

First, it can be helpful for Scrum Masters to recognize that the Agile manifesto value of “Working Software over Comprehensive Document” is a struggle for many Project Management Offices ( PMO) and Business Analysts (BA). Organizations and firms which are heavily regulated have strict requirements on detailed project artifacts in order to pass audits and the PMOs and BAs are oftentimes the creators and/or keepers of these documents. In short, it’s a balancing act to the find the appropriate and agreed to level of documentation that meets everyone’s needs. These discussions and agreements can take place during Sprint 0 and reviewed in the Release Planning meeting.

UnicycleSDBC2004

 

Waterfall/RUP documentation habits die hard with some seasoned BAs. The urge to analyze, research and detail out full use cases and system requirements prior to the start of sprinting can be strong for those who are new to iterative development and User Stories.   The Scrum Master’s coaching and guidance on the Agile best practices for User Story creation and refinement are critical to keeping the project moving along and not getting bogged down in analysis paralysis.

And then is there is the battle of what tools to use to document and where to store the project and requirement artifacts. Boy can opinions and passions run hot in this area!   Whether you use TFS, Rally, Jira, VersionOne, PivotalTracker or any other application for tracking your User Stories, sprint tasks and velocity, your Scrum team and the Project stakeholders need to understand and come to an agreement that certain Requirement Documents of Record can should be stored, tracked and linked to in other repositories like Sharepoint or Blueprint.   Traceability is a key concern for many organizations and should be addressed in your Team Agreements and processes.

The Goldilocks Dilemma

How much detail do we need to put in a User Story? This is another deeply philosophical question and everyone seems to have a different opinion on it.

How much is too much? How much is too little?   What level of information and detail is just right?

 

3bowlsv3

As Scrum Masters, our role is to strike the right balance with the Product Owners, BAs and PMs so that the needs of the organization are met without sacrificing the benefits of the iterative design and development. This is certainly easier said than done but know that you are not alone in this challenge.

It helps to explain that details on the requirements will be uncovered and documented in a more collaborative manner with ongoing conversions and meetings with the entire team. Requirements will not be created in a vacuum and will be refined /groomed/ sized by the scrum team.

It occurs to me that this topic is important and meaty enough to deserve its own article, so I’ll dive into the details of User Story Creation in Part 3 of my “Confessions of a Scrum Master” series next week.

The behavioral changes involved in adopting the Agile can be uncomfortable and difficult for many people and teams. Documenting requirements in Agile often requires a significant shift in process and the Scrum Master’s coaching and facilitation role is critical to helping the team to learn and understand the value and benefits of iterative development while allaying their fears and concerns about the “new and different” way.