Q1: Dealing With Sprint Dates and Releasing Incremental Functionality

Q: We see that there is a start and end-date for a sprint. But, what if a client wants to release the incremental functionality as soon as it is ready for release. How do we support this?

A: By definition, any increment identified in an iteration/sprint when approved by the product owner can be immediately released to production (if there is a binary code) or to the customer (if not code related like documentation, training, etc.). So, you don't need to modify the release/sprint. Instead, use a transition/operation step at the appropriate level.

For instance, in the requirement workflow, you have a "Completed" status and "Released" status. You can add a "Release Early" and "Release at the end" moving the item from "Completed" to "Released". If you do this, based on best practice of agile transformation, it is recommended to add a custom date field of "Release Date" or something like that. This field should be a required field at the "Released" status so that if you release early during the sprint, this date can be populated and tell a story of how much was released early during the sprint. I have also used these approaches to coach team/client to tell escaped defects that are associated with such early releases because of acceleration requests and inadequate testing prior release.

Q2: Making Changes to Stories Once the Sprint has Started

Q: Requirements are generally getting discussed and finalized during the sprint period itself and not before starting the sprint. Similarly, priority is also very dynamic. If we can distinguish such cases using some custom field and generate a report with that custom field to project all such cases to senior management would be a good idea. Could you please provide your suggestions?

A: The above is a classic Agile anti-pattern; so, these are not Spira specific but process oriented.
Once a sprint/iteration starts, if any change has to be done to the stories committed, the sprint/iteration must be terminated. The principle of "Embrace changes late" applies until the iteration planning but once iteration starts, changes are locked. The client or any stakeholder has the opportunity to refine the backlog of prioritized requirements much before. In fact, when I manage agile initiatives, I encourage the N+2 principle. That is, if we are working the Nth sprint, the risk-adjusted product backlog must have enough user stories defined for 2 upcoming sprints.  The priority or the requirements can change until the iteration planning meeting starts where people commit to user stories. Otherwise, the team should be empowered to reject committing to any stories. In fact, even in my non-agile projects that follow progressive elaboration, these are considered scope creep and a change request has to be followed for the client to absorb the impact to schedule, cost, and quality. I bring the concept of risk to make sure that client absorbs the cost of change.
So, although you can add custom properties for these reasons, we are allowing the tool to propagate an unhealthy anti-pattern. Instead, the product owner, scrum master, and the client should be coached on agile and project management principles. Once a sprint gets terminated and a new sprint is started because of changes in requirements, the timeline is constantly shifting and the operating rhythm is impacted for the team. It is the scrum master's role to avoid these antipatterns and coach on the correct use of Scrum and/or Agile principles.

Q3: Dealing with Parallel Sprints

Q: What is a parallel sprint? Does Spira support it? What guidelines do you offer while doing parallel sprints?

A: A parallel sprint is two or more sprints that are running in parallel. That is, they overlap somewhat. They need not start at the same time (SS dependency) or finish at the same time (FF dependency). However, if they do start or end at the same time, there are complications in the form of people available to plan the start or end of the two sprints. SpriaPlan supports parallel sprints by giving control over the start and end dates.

Based on agile principle, sprints are meant to be sequential so that feedback can be obtained from the customer on the increments and iterate in subsequent sprints. If two sprints are happening in parallel, then, there needs to be some considerations. These are as follows:

Due to the increased need to communicate and collaborate on all these elements in meeting the sprint commitments, it is generally not recommended unless there is a major business driver.

  • Risks: Multiple parallel sprints mean there may be resource dependencies. People working on different user stories in the sprints can be subject to risks in delivering on their commitments.
  • Resources: If parallel sprints share the same infrastructure, then, the risks may manifest in the form of waiting time. The waiting time is not aligned with the lean principle of flow.
  • Requirements: The purpose of parallel sprint is to increase speed with multiple teams. The goal is not to have the same requirements being worked on simultaneously in two different sprints. Doing so means the “Independent” nature of the INVEST property is not upheld.

Q4: Incomplete Tasks/Tests Cases in Closed Sprint

Q: Why is the sprint allowed to be closed when the user stories and associated tasks or test cases are still not completed?
A: According to the Agile principle, a sprint can be prematurely terminated. This is the same process for traditional projects that can be terminated before the close date. So, we do not enforce all the requirements to be done, tasks to be completed, test cases to be passed, and incidents to be closed before moving forward with a sprint closure.

Q5: Differences in Behavior Between Task and Incident Remaining Hours

Q: When incidents are marked completed, the remaining hours are not zeroed out. But, completion of the task zeroes out the remaining hours. Why?
A. In general, tasks are created and assigned for individuals to complete the work. So they know clearly the work that needs to be done. So, even if you have remaining hours, it is zeroed out when the task is completed. Since we know exact statuses (you cannot create new task status similar to incident status), this makes completed the final state.

We can't say the same for incidents. First, we don't know if it would be the final status as you can add your own incident statuses. Besides, the defect triaging process itself may mark a defect completed with remaining hours still valid because the completed status is not the final state. As a result, we don’t zero out the remaining hours.

Q6: Entering Requirements on the List vs. Detail Views and Required Fields.

Q: Why do we allow entering requirements in the list view when mandatory fields are not filled?
A: By design, anyone should be able to enter requirements. But, it is the product owner or the scrum team that can refine them, prioritize them, and plan for them. Since Spira is framework agnostic, we allow a requirement to be entered in the list view without enforcing the mandatory fields since those fields may not even be displayed in the grid. But these fields are enforced when they are being worked on in the detailed view.