A sprint is a core element of the popular Agile project management framework which facilitates an iterative and flexible approach to completing deliverables of a project. In a sprint’s planning phase, the requirements are reviewed by the team, scored based on effort, and assigned accordingly. This approach is especially helpful when project requirements change over time, or if the full breadth of requirements is unknown in the onset.

Comparing a Sprint with the Play Card
When considering the Play Card Methodology in the context of using the Agile framework and sprints, there are several mutually shared features. For example, both leverage the daily touch base (or stand-up) to discuss progress and obstacles, both offer an iterative approach to delivery, and both promote continuous improvement through the use of post-project retrospective. However, each provides its own distinct features based on their underlying design. The expression of deliverables and the sub-division of the sprint are two key examples.

Deliverable expression
Typically, a committed deliverable within a sprint is expressed as a combination of a user story and a collection of specific tasks associated with the user story. For example, a simplified user story may say “As a user, I can view a list of active requests from customers.” An example of a subsequent task may be expressed as “Code the query to obtain the data.” When the Play Card Methodology is applied to the deliverables of a sprint, the user story and tasks are expressed together as a weekly SMART goal. For example, the week’s goal for the sprint may be expressed as “Code the query to obtain the data to view a list of active requests from customers, unit test the results, and have the data available to the user interface team by February 22nd.” The design of this difference is to attempt to eliminate ambiguity in the deliverable and clarify the expectations of the team.

Subdivision of time
A common practice is to define a sprint to span between two to four weeks. During the sprint, the team focuses on progress and presents the results either through a feature demonstration, or user acceptance testing, near its conclusion. The Play Card further subdivides the sprint into concrete, weekly segments. Each segment provides a framework in which goals can be expressed, progress can be measured, obstacles can be identified and mitigated, and updates can be communicated to stakeholders efficiently.

A more agile sprint
In our experience with traditional sprints, there is always a temptation to reduce the sprint to a single week. This is often precipitated by a perceived rigidity of a multi-week sprint, or the stakeholder is interpreting the delivery of a feature as a measure of progress. However, with the use of the Play Card Methodology, the desire and need to implement short sprints, of minimal value, can be eliminated. The weekly goals offer the team easy to digest expectations, and the stakeholders clear indication of progress. Since the following week’s goals can be quickly modified, the Play Card offers an additional degree of flexibility to deliverables which preserve the longer (2-4 week), higher value, sprints.

The decision to utilize the Play Card Methodology is not intended to be one to replace or eliminate sprints. In fact, the two are highly complementary models. The Agile framework has proven to be a highly useful tool which has bee refined over several decades. The Play Card Methodology has been born out of years of effort to overcome the pervasive challenges of communication between development teams and their customers. Consider the concept of the Play Card Methodology as a “plug-in” which is intended to augment the communication features of the core Agile framework.