What does the 2nd Agile Principle (Welcome Change to Requirements) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the second Principle to better understand what it means and to attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage is the second Agile principle. From an Agile perspective, you embrace change to increase the chances of delivering value to the customer. You embrace change because you understand that change is necessary as customer needs, market conditions, and general demand change over time. 

Welcoming change implies several qualities. The first is that there is a positive attitude toward change from the team and management. The second is that while change ideas are admitted, they are methodically prioritized based on customer value along with existing requirements. The third is that there is a process that allows prioritized changes to flow without obstruction.

What actions may exhibit “welcoming change to requirements”? Some evidence includes:  

• The PO continually engages with the customer to identify new requirements or changes to existing requirements. 
• A methodical review of the change idea occurs to determine the priority amongst the existing requirements.
• No person or process restricts incoming change ideas. 
• The backlog is continually refined and reprioritized. 
• Increment Planning and/or Sprint Planning is applied to introduce the newly prioritized requirements. 
• Continuous customer engagement via customer visits and sprint reviews are applied. 

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, if you really believe in this principle is, do you welcome change?

-------------------------------------------------------------------------------------------------

To learn about what evidence might look like to support the 1st Agile Principle (aka, Satisfying Customer with Valuable Software), consider reading: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html

Requirements Tree: Focusing your efforts on the highest value work

Requirement is a nebulous term.  It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing. 

To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree.  It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature.  Think of it as your requirements lineage. 

What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door.  Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.  

What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours.  I like to start with corporate strategy and end with tasks as illustrated in the figure. 

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level.  Using the requirement levels from the figure, here is how I describe each level.  A strategy sets  direction for the enterprise.  An idea is a high customer value and outcome-based opportunity.  An increment is an end-to-end slice of the idea to provide value and validate of the idea.  An epic is a function or feature.  A user story is a requirement that fits into a sprint of a week or two and has one persona.  A task is a very small unit of work that incrementally builds the user story. 

In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level. 

You may notice that instead of putting the strategy on top, I place it on the bottom.  I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on. 

The key to your requirements tree is for you to establish one that makes sense for the type of work you do.  For example, if you only have one division in your company, then a division strategy isn’t necessary.  You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members.  Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.

Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise". 

 

Agile Requirements - A Promise for a Collaborative Conversation

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, it is to begin the collaborative discussion. 

In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side more thoroughly understands the business value of the requirement and the business side better understands the technical options of the requirement.

It goes much deeper than this.  In the old world, there is a typically only a one or few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘thrown over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement and then continues with the fleshing-out of the requirement in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 

From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning (depending on your approach) where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 

• Understanding why it is a high priority
• Validating/updating the User Story is in Canonical Form (or defined form)
• Understanding the business value and customer perspective
• Describing acceptance criteria
• Considering high-level technical details
• Identifying unknowns and risks (each should have an action to investigate and mitigate)
• Identifying what is out of scope
• Identifying dependencies
• Decomposing epic to user stories or each user story to tasks
• Providing high-level sizing (e.g., t-shirt sizing, story points, etc.)

As the collaborative discussion ensues (usually in a time-boxed manner), the requirement gains more clarity and robustness, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 

Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.

User Story Writing Starter Kit

Prior to Agile coming into existence, I was fortunate to learn how to write requirements by Elemer Magaziner (i.e., business requirements) and Alistair Cockburn (i.e., use cases).   They provided various alternatives to writing clear requirements that were irrespective of methodology.

 

From this I learned that there is a strong benefit to establish what I term as the “requirements language construct”.  This construct helps you consistently document your requirements focusing on key requirements elements. One common requirements language construct in the Agile world is the canonical form. It is important to realize that elements of the canonical form have been around for years.   With that being said, the three basic elements of the canonical form provide a good framework for establishing requirements. 

First I will discuss the user story that is typically expressed within the three-part canonical form.   Then I will introduce the enhancement of a requirements language construct that can adapt the canonical form.  The language construct for a user story in canonical form looks like this:

The persona is the user type who will receive the value.  The action is what the user type desires.  The business value is the benefit to that user type.  Note: you can learn more about personas in the article Personas – Do you really know your Users?   The following are examples of user stories in canonical form:

• As a learner (persona), I want to set up my profile to include my photo (action), so that my distributed team members know what I look like (business value).
• As a prospective buyer (persona), I want to search on homes (action) so that I know what properties are available in my price range (business value).

As enhancements to this construct, you may consider adding the system that will be used or interacted with and the receiving entity which identified the expected output from the requirements.  If applying these, the requirements language construct would look something like this:

As a (persona)

I want (action) from (system) to the (receiving entity) 

so that (business value)

The following are examples of user stories with these enhancements.  The first example below takes the second example from above and enhances it with the system and receiving entity.

• As a prospective buyer (persona), I want to search on homes (action) from MLS (system) to a separate window (receiving entity) so that I know what properties are available in my price range (business value).
• As a quant analyst (persona), I want a derivatives report (action) from the asset management application (system) in the form of a pdf (receiving entity), so that I can distribute it to my fund managers (business value).

There is no “right” requirements language construct.  It is important to craft one and then experiment with it.  I would suggest starting with the canonical form and work from there. 

Finally, the Product Owner, Business Analyst, Product Manager, and anyone who writes requirements should be trained in writing user stories in whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. You may also want to train stakeholders and customers on how to provide their needs in your requirements language construct for consistency and clarity. 

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 18 of Being Agile. 

Personas – Getting to really know your Customers

When you are building your product, how well do you know your customers?  Can you visualize who they are?  Do you understand their motivations?  How do you know you have requirements or user stories for all of the various customer types that you have?   By knowing who your personas are for the product or solution you are building, can help you answer these questions.   

Personas represent specific users and act as examples of the types of users who would interact with it. Most products have several personas that use the product in different ways. Examples of three personas for a product are the regular user, power user, and administrator.

• The regular user uses only the basic user interface functionality.
• The power user needs more detailed interface functionality to handle more sophisticated work.
• The administrator needs back-end installation and maintenance functionality.

All three use the product differently, and different features are built for their respective needs. Personas are a powerful way to guide your decisions about functionality and ensure that you are, in fact, building functionality for each persona. Personas are a key ingredient in the way that user stories can be presented. Including the persona in a story description provides you the point of view (POV) of a user story and defines who that user story is for.

I recommend that you establish a description for each persona. This description is typically illustrated as a fictitious person that represents a real role. It will include the knowledge, experience, and activities of that role. By writing a persona as a fictitious person with a name, this makes the persona easier to imagine and relate to, as in the following examples.

Consider establishing personas for your products so that the functionality can be better understood and help you build a product that better aligns with your customer needs.  Finally, personas offer four distinct advantages. 

• The team understands the users better, which helps guide decisions about the functionality they need. 
• User stories can be written to include the persona to ensure the personas have requirements suited to them. 
• Testers can create acceptance tests and use cases that support personas. 
• Based on their personas, the Product Owner knows who can give the best feedback and therefore whom to invite to the reviews or demos.  

You can read more about Personas in the book entitled Being Agile in Chapter 17 in relation to customer reviews and demos and Chapter 18 in relation to writing effective user stories. 

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.