Techniques Following Agile Development Practices

Agile methodologies have revolutionized the way software development teams work, allowing them to deliver high-quality software faster than ever before. The ability to write Team User Stories is one of the fundamental agile development practices. 

Here, we examine the top approaches to Team User Stories, divulging crucial best practices that are useful at every stage of your learning expedition. By following these core techniques, you can gain the aptitude and knowledge essential to implement winning team tactics. Nevertheless, it's essential to note that Team User Stories constitutes just one piece of the larger picture. To obtain a comprehensive understanding of your team's ongoing process status, we recommend availing yourself of our free agile assessment for Team Agility.

Team User Stories and The Learning Journey

At Lean Agile Intelligence, we recognize Team User Stories as the team's ability to create software requirements in an agile fashion. We divided the learning journey into 4 different stages: Developing, Emerging, Adapting, and Optimizing. In the following sections, we will discuss each stage in detail as well as provide practical tips and techniques to help you strengthen your skills in this area.

Source - User Story - Team Brainstorm Session

Developing

Teams that are “developing” an understanding of the value of Team User Stories and adopting the foundational techniques should focus on the following improvements

• The What: The team uses User Story format and collaborates on the details

  • The How: A “user story” originates from the extreme programming framework originally created by Kent Beck and Ron Jeffries. More info on XP can be found here. User stories are defined by the “Three C’s”

    • Card: Originally user stories were written on index cards (This was pre agile tools!) with a sentence or two. The card should trigger a conversation and not read like a spec, so by its very nature, it starts off very sparse. It can be in the format “As a user, I want, so that…” but it should be noted that format was not created by Kent or Ron and was added later by people working at contextra in 2001 and that format was intended to be used more as “training wheels” to have a conversation

    • Conversation: Arguably the most important aspect of a user story by design is the conversation that occurs between customers or customer representatives like Product Owners and the development team. These conversations should flesh out why the story is valuable, who it’s for and what ideas are possible to achieve the value for a specific type of user. In addition, conversations about how a story contributes to an MVP are extremely valuable.

    • Confirmation: In a user story, confirmation is in the form of “Acceptance criteria.” More about that below…

• The What: Acceptance Criteria is present in all committed stories

  • The How: Acceptance criteria is the “confirmation” part of the three C’s. In XP, acceptance criteria are meant to be a set of behaviors to be automated. Many companies treat it like a combination of an automated and manual checklist for determining when a user story is “done.” We have written a blog post about this topic here.

• The What: Stories are small enough to be delivered in an Iteration (i.e., Sprint)

  • The How: User stories at a minimum should be sized by the team to be completed inside of the iteration length. Some teams opt to focus on stories that can be completed within one week as stories will be started at many points during an iteration. Many high-performing teams focus on splitting stories so they can be completed in 1-3 days which helps reduce the batch size of tasks in a story and can aid in the reduction of story cycle time.
    
    

Emerging

Teams that are “emerging” beyond the foundational techniques of Team User Stories and are embracing it as they become more proficient, should focus on the following improvements

• The What: The team ensures consistency exists across stories when it comes to format, details, artifacts, and impacts

  • The How: It’s a good practice to add story writing standards to your team working agreements. As the name suggests, “working agreements” should be agreed upon by everyone on the team. In order for them to be effective, they should be created with input from everyone on the team using group facilitation techniques. In this post by Thomas Kuryua, Thomas details a fantastic approach to facilitating a working agreement session.

• The What: The team leverages research spike stories to mitigate risk and create learnings

  • The How: A research spike is a type of PBI that is dedicated to reducing uncertainty for refinement, planning, and estimation purposes. An In-depth look at spikes can be found here.

*   *   *   *   *   *

"It’s a good practice to add story writing standards to your team working agreements."

*   *   *   *   *   *

Adapting

Teams that are “adapting” the Team User Stories practice to extract the full benefit, should focus on the following improvements

• The What: All work required by the team is written as a User Story, including refactoring, research spikes, architecture runway, and infrastructure work

  • The How: For non “user” facing stories like enablers, you can use a technique called “Feature Injection” described by Liz Keogh in her blog post, which can be found here. Feature injection helps technical stories describe the business benefit. The format is…

    • In order to <deliver some business benefit>

    • As a <role> I want <some other role>

    • to <do something, or use or be restricted by some feature>.

Source - User Story

Optimizing

Teams “optimizing” the knowledge sharing of the Team User Stories practice learnings across the enterprise should focus on the following improvements

• The What: Stories are Independent, Negotiable, Valuable, Estimable, Sized, Testable (INVEST)

  • The How: INVEST is a story writing technique first described by Bill Wake. It states that stories should first be independent and that means independent of one another. A common anti-pattern is to split stories by task, ex: A front-end story, a back-end story, a research story, etc. These types of stories are dependent on one another to achieve any real value. Stories should also be a negotiation between the customer and the development team. They should have a clearly stated and well-understood value by everyone on the team. They should be understood well enough to be estimated. They should be sized small enough to fit into an iteration, and they should be testable. More details can be found here.

*   *   *   *   *   *

"All work required by the team is written as a User Story, including refactoring, research spikes, architecture runway, and infrastructure work."

*   *   *   *   *   *

Conclusion

In conclusion, the use of Team User Stories is critical in promoting accountability and identifying areas for improvement. It is essential to recognize that developing a team's proficiency in User Stories is a process that takes time, and foundational techniques should be the focus at the beginning. Eventually, a team will emerge from foundational techniques and begin to leverage research spike stories to mitigate risks and create learnings. It is also important to negotiate and refine stories with collaboration from required stakeholders, ensure that sprints are rarely interrupted by non-ready stories, and write all work required by the team as a User Story. By implementing these improvements, teams will be able to strengthen their skills in Team User Stories, which will ultimately lead to better software requirements in an agile fashion. For a thorough assessment of your team's current process status, we offer a free agile assessment for Team Agility that you can take advantage of.