Achieving Business Outcomes and Predictable Delivery

A “sprint” or team iteration in scrum is a planning and iteration time box in which increments of value are delivered. A sprint starts with sprint planning and ends with a retrospective and delivery is not bound to the timebox. Having consistent and effective sprints can help lead to successful business outcomes and predictable delivery.

This post delves into the most efficient methods to tackle Team Iteration and reveals vital best practices that can be adopted during various phases of your learning journey. By adhering to these fundamental techniques, you can develop the competence and awareness necessary to execute effective team strategies. Nonetheless, it's crucial to recognize that Team Composition is only a fragment of the broader context. To attain a comprehensive insight into your team's present process status, we suggest using our free agile assessment for Scrum.

Team Iteration and The Learning Journey

The ability to achieve a goal by delivering a potentially shippable product increment within a time-boxed period is critical for any successful team. As mentioned above, at Lean Agile Intelligence, we refer to this process as Team Iteration. Our learning journey consists of four stages - Developing, Emerging, Adapting, and Optimizing - and in this post, we will delve into each of these stages, offering practical insights and strategies to help you improve your skills in this area.

Source - Agile Methodology

Developing

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

• The What: Iterations (i.e., Sprints) have consistent durations of no longer than a calendar month to enable predictability and risk management.

• The How: According to the scrum guide, sprints should be one month or less. Most teams choose two-week sprints but sprints can be any length as long as they are no longer than a month. Some teams find success in having shorter sprints which means shorter and more frequent scrum events and faster feedback. Sprint lengths should be consistent to help with predictability and forecasting and should not be changed based on the scope of work but the amount of work within a sprint should change based on team capacity.

• The What: Each Iteration (i.e., Sprints) contains an objective goal (i.e., Sprint Goals)

• The How: One of the fundamental aspects of a scrum team is achieving common tangible product and team goals. Since scrum is an iterative process, we must set goals, achieve them, and then inspect and adapt based on feedback. A sprint goal states the purpose of a sprint while acting as a shared objective for the team to achieve. Roman Pichler has a fantastic template that you can use to formulate sprint goals. You can utilize the entire template or whatever is appropriate for you context.

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

• The What: Iterations (i.e., Sprints) are no longer than two weeks to generate more learning and accelerate value delivery

• The How: While the scrum guide states that sprints should be no longer than a month, we recommend based on industry experience that sprints should be no longer than two weeks for most contexts. In order to achieve the desired results that most teams and organizations are looking for such as building the right things, faster delivery, and higher quality, we must shorten the feedback loops as much as possible. If you are struggling with getting down to two-week sprints, try executing a one-week sprint. While it may sound counter-productive, it will help you learn how to break down work in such a way to be able to deliver a small goal within a week. Just the practice of doing a one-week sprint will help make two-week sprints an easier reality.

Adapting

Teams “adapting” the Team Iteration practice to extract the full benefit, should focus on the following improvements

• The What: No changes are made to the work of the Iteration that endangers the goal from being achieved

  • The How: Since the sprint goal is a tangible business and or technical goal agreed upon by the product owner and delivery team, it’s critical that all changes made to the sprint backlog during the sprint are done keeping the sprint goal in mind. If the sprint goal is no longer valid, the team should replan for the rest of the sprint and create a new goal.

Source - Why Agile Teams Should Sometimes Fail to Finish Items

Optimizing

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

• The What: Each Iteration results in a potentially shippable product increment

• The How: An “increment” is referring to a small piece of a larger solution that is built both iteratively and incrementally. Jeff Patton has previously illustrated a very easy-to-understand breakdown of the difference between iterative and incremental development. In scrum, we do both.

• “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” - The Scrum Guide 2020

• 

  This is an example of purely incremental development. If you know the exact end state and there will be no changes or deviations and you can predict with 100% accuracy what will be valuable then you can use this approach. Start with defining everything up front and deliver small pieces until you have the final solution. Often scrum teams work this way that are transitioning from waterfall. They are comfortable with defining everything up front, breaking down into hundreds of stories and then delivering them working towards a specified date.

  

   

• This is an example of purely iterative development. This assumes that you have an idea of what you want but are not sure exactly what it will look like in the end. The differences from the previous picture are starting with an idea instead of all the “requirements” and delivering an end to end version of that idea to collect feedback on and adjust along the way.

  

   

• In practice, high performing scrum teams use both techniques at the same time. They start with an idea or hypothesis, create an end to end version of it for feedback but include things that are the highest priority that will likely be kept in the end product and continue this process from sprint to sprint. At any time they can stop development and get value from the increment that has been iterated on and leave the rest. In the above picture, they could stop at step 3, crop the head and sell the painting as portrait of Mona Lisa.

*   *   *   *   *   *

"While the sprint goal should remain in tact, the sprint backlog can be a living, emergent, set of items needed to complete the sprint goal."

*   *   *   *   *   *

Conclusion

In conclusion, by adhering to these fundamental techniques, teams can develop the competence and awareness necessary to execute effective team strategies. However, it's crucial to recognize that Team Composition is only a fragment of the broader context. Having consistent and effective sprints can help lead to successful business outcomes and predictability of delivery, making it a crucial aspect of Agile methodology. To attain a comprehensive insight into a team's present process status, it's recommended to use a free agile assessment for Scrum.