Requirements in Scrum

Let's be honest. Most teams struggle with how to get requirements into their new "agile" process. Take Scrum for instance. Scrum says you start with what is called a Product Backlog. Let's see what the Scrum Guide says about the Product Backlog:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

The only guidance that the Scrum Guide gives for the Product Backlog is that it has these attributes:

Product Backlog items have the attributes of a description, order, estimate and value.

If you are coming out of a non-agile process, you are normally used to seeing requirements in the form of a BRD (Business Requirement Document), TRD (Technical Requirement Document), Functional Spec, etc...People spend countless hours writing these documents and in my experience, no one ever reads them completely. Typically because developers know the requirements have changed as soon as they get them or that the language from the customer is not clear, or worst yet, the customer really has no idea what they want. They know what problems they have, but rarely know exactly how to fix them with software (that's why they hired us right?)

Given that Scrum doesn't prescribe the actual technique to write requirements, we have to determine what works best for our team while adhering to the Scrum Values and Agile Manifesto Values / Principles. This is actually a powerful part of Scrum. That is why its called a process framework; not a methodology. Scrum doesn't prescribe how to do certain things. We are left to decide as a team. Professional teams usually have no problem figuring out the best way to work.

User Stories are a common way to get requirements into the Product Backlog. They are, however, largely mis-used. We actually borrow User Stories from the Scrum cousin process called Extreme Programming. Ron Jeffries formally provided some guidelines on a User Story after Alistair Cockburn visited the Chrysler C3 Team in Michigan (the first XP project).

Without going into detail about the history of a User Story (which is fascinating), let's talk about what the purpose of a User Story is for our Scrum Team. It is the vehicle in which we receive requirements. The difference between a User Story and Functional Spec is that the User Story is informal while the other types are formal requirements. The main reason we want the informal requirement is to foster conversation within the team about the requirement. We are moving from documentation to discussions (you can still document your discussions however).

Through the collaboration and discussion, the teams gain a clearer understanding of the need/problem and have a united view of the problem. Our customers / Product Owner brings the "What we need to build"; the problem. The Development Team formulates a solution (the "how we are going to build it"). We truly won't know if we have solved the customer's problem until they can empirically experience the product we built. A requirement document doesn't let the customer "experience" the product. Our goal in a Sprint is to turn those conversations into working product so that we can get feedback.

User Stories definitely have some typical formats to follow. The format however is more of a guideline not a rule. A widely used format is:

"As <some role>, I need <some feature>, so that I can get <some value>".

The main take-aways we want in a User Story is that we are communicating the actor of the story (who is this person / system that will need this feature). We then listen to what the customer is describing in their need (what is the feature they need). Finally observe the motivation. Why is it that they need to do this action? This is possibly the most important part of a User Story. As the team learns the reason the actor needs to be able to do something, they might pivot altogether on the solution and change the feature as they converse about what they are really trying to accomplish. The conversation is the most important part of the User Story.

User Stories typically start out a bit ambiguous and vague. Through the discussion, we gain clarity and can start breaking the work down into smaller pieces. We want stories to be actionable within our Sprint Time-box (stories that are too big to fit need to be broken down). We can then attach designs, discussions, and anything else we need as part of building the feature onto the User Story. We need to ensure the story is ready to go for a Sprint. There are many techniques that teams follow to do this; but one of the best tests to ensure your story is ready for a Sprint is found in Bill Wake's INVEST model. This is a good lens to ensure our team has the information needed to actually begin working on the story. We have to be comfortable with details emerging in the Sprint itself, but we do need a good guideline so that the team feels confident they understand the goal of the story.

User Stories can work for any types of work you are trying to accomplish. They are not relegated only for software teams. Give it a try next time you are trying to convey someting you need to someone else working for you. Also remember, that we don't expect every single Product Backlog Item in Scrum to be in the format of a story. It is a good practice, but there will be times it doesn't make sense. Take a defect for example:

"As a customer, I want this defect fixed, so that I am not frustrated".

Many teams spend hours trying to make sure the format is correct. If it doesn't make sense, then just log the item in the Product Backlog ("Fix Defect 1019283"). Usually those will come from the customer or a support team and have details on how to reproduce or a description of the error.

User Stories are a refreshing way to receive requirements in our Product Backlog. They do take some practice, so be patient and try them out. You will find that requirements through the exchange of conversation are much more valuable (and faster) than writing and NOT reading a requirement document.

Related Articles

What Does it Mean to Be a Certified ScrumMaster®?

What does it mean to be a Certified ScrumMaster® (CSM) and how will it help your career goals? Can you get hired as a Scrum Master without a certification? Let’s explore the pros and cons of certification, what it means for your career and how to obtain your certification if...

Read More

Plan Your Wedding with Scrum

So many people think that Scrum is an IT-thing, but Scrum is such a flexible framework for managing complex products and projects that it can be applied just about anywhere! We’ve seen Scrum used in technology, marketing, finance and human resources, but guess what—it’s not just a framework for business...

Read More

The Role of a Project Manager in Scrum

We had a great turnout at DFW Scrum last TUE for "The Role of the Project Manager in Scrum". Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself facilitated this fascinating conversation. The reality is, there is not...

Read More

Are You Ready to Sprint? (Tips for Getting Your First Sprint off to an Amazing Start)

Getting started with Scrum doesn’t need to be a laborious process, but there are a few things you want to settle with your team before you take off sprinting. Teams that are organized around outcomes, have the right people on the team to deliver valuable work, can commit to a...

Read More

How To Grow Scrum at Your Company without a Heavy Framework

Now that your company’s mastered the Scrum framework at a team level, it may be time to expand it to multiple teams or areas of your organization. While you may be thinking you need to learn a scaling framework such as SAFe, Scrum@Scale, or LeSS; there are many things you...

Read More

Beyond Software: How Scrum Helps Marketers Succeed

Just because a group of software developers popularized Scrum doesn’t mean it’s a technology framework. In fact, their inspiration actually came from a white paper called The New New Product Development Game, which had a lot more to do with business than tech. For the past 20 years, Scrum has...

Read More

Unleash the UI/UX Power in Scrum

There is a wide perception that Design in general is just making things pretty, choosing colors and pictures. However this mostly describes the activities related to UI and does not take into account UX at all. UI/UX are often compared with an iceberg where UI is on the top including...

Read More

How Scrum is like American Football

Scrum really is a team sport. We don’t win the game by individual contributions. We win the game by playing well together, much like in American football. In fact, Scrum is so similar in many ways to this sport, so let’s take a closer look. The Huddle is Like the...

Read More

Core Scrum Roles

Just like the US Government has 3 branches (Judicial, Executive, and Legislative Branches), Scrum has 3 roles. Many people compare the counter-balance of each roles in Scrum to that of the US Government. It's really about the checks and balances. But I truly believe it is even more than that...

Read More

Unlocking Agile's Power in the World of Data Science

In this episode of the "Agile Mentors" podcast, I discuss integrating Agile and Scrum practices in the world of data science. Tune in to gain insight into the importance of feedback, the stages of the SAS Enterprise Miner initiative, and how frameworks like OSEMN can enhance the data science process...

Read More

So you want to do Scrum?

What do you truly want? I have spent a career helping organizations go from whatever process they are doing to wanting to be more agile. The request typically starts with "We would like you to come in and conduct some Scrum Training". Great, I love conducting workshops and helping people...

Read More

We can't release until the end of the sprint...

As I work with Scrum Team's, I find a common thread in teams that believe our releases are "tied" to the Sprint time-box. This is not the case. Releases are independent of the Sprint time-box. If you have something that meets the team's definition of done, the Product Owner has...

Read More

Organizational Rhythm

Rhythm...let's define that word really quick before we move on: a strong, regular, repeated pattern of movement or sound In music, that rhythm is the foundational cadence that allows multiple musicians to play together and deliver one common, in-tune, and usually beautiful song. If they didn't have that common cadence...

Read More

Is Your Team Focused with a Sprint Goal?

One of the 5 values of Scrum is Focus. Too often, I will ask Product Owners "What is the goal of this sprint"? Their response? "To get all of these Product Backlog Items done!" (and they look at me like...duh!) My question is focused on ensuring that our Development Team...

Read More

Stop Starting and Start Finishing

Ever run in a race or participated in a track meet? No matter how far the distance, when you cross the finish line, you’re done. It’s easy to understand and you don’t have to linger around, waiting for anything else to happen. What happens when you need to get an...

Read More