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.

 

 

 

 

 

Advertisements

Confessions of a Scrum Master

Every thing I needed to know about being a good Scrum Master I learned from my high school soccer coach, Miss Lonegan.

Slide1

Here’s what was instilled in me on a muddy soccer field in the early 1980s.

Great coaches and leaders:

  1. Motivate and help the team to be successful.
  2.  Walk with the team, on the field, everyday.
  3.  Teach others the process by sharing fundamental tasks and techniques.
  4.  Guide the team without being overly controlling.
  5.  Communicate positively.

These successful actions and traits recently dawned on me when I realized how important Personality and Temperament are to being an effective Scrum Master.

Over the past 5 years, I have been observing team dynamics as a Scrum Master (SM) on multiple teams in 3 different companies and have witnessed a number of SMs crash and burn due to not leading like good coaches. Lack of communication and soft skills were also a common theme with the ineffective Scrum Masters.

The most successful SMs are true team players and are comfortable surrendering control to the Product Owner and team. Adept Scrum Masters truly view their role as being in service to the team, removing obstacles for the team and helping them to be successful.

Facilitation is another important role of the Scrum Master and requires a high level collaboration and strong, tactful communication skills.   The authoritative, directive, ” my way or the highway ” approach does not work well with Scrum teams.

Project Managers can sometimes get away with a lack of soft skills but Scrum Masters, who are facilitators and coaches, cannot.

In the Retrospectives with our team, I ask them to think about the Results, the Experience and the Process of Agile and the sprint. I view my Scrum Master role as critical to helping the team to not only achieve great results (velocity) but to enjoy the experience and the process- just like my high school soccer coach did all those years ago!