Manage testing and development in same sprint to avoid spillover

Is it a good practice to split story into Development and Testing? Please share your thoughts.

In my opinion, this is a terrible practice and in my experience has never worked for any reason it has ever been tried.

How do you know if the development work is providing value if you haven't validated that it works as expected?  The goal of a Sprint is to deliver a working increment of work that delivers value to the stakeholders, satisfies the Definition of Done, and fulfills the Sprint Goal. 

If you start to split stories into development and test you will be adding complexity and time to the work.  Work that is developed might be sent back based upon failing tests.  This means that developers will have to refocus themselves on something that has been "completed" and break their attention on the new work. This constant focus shift will eventually lead to delays in getting something through your process which will decrease the value in the stakeholders' view. 

There is also a high possibility that things that development has "finished" will queue up for testing and make things fall even farther behind, especially if there is a constant build/fix/correct/fix/correct cycle.  

The reason you want to complete all activities that will make work valuable, "done" and deliverable is to make your delivery more reliable and consistent.  The reason companies want to say that they are "Agile" is to deliver faster.  The suggestion and tendency in practice is going to be waterfall and subject to unwanted delays.

We ensure to split the story effectively but still sometimes it becomes difficult to accommodate development and testing in same sprint which results into expected spillover.

What are the consequences of this for the Sprint Goal?

Is it a good practice to split story into Development and Testing? Please share your thoughts.

Does it seem like a good way of ensuring that planned work is Done, and fit for immediate use, every Sprint?

Remember that a user story is a placeholder for a conversation about a possible requirement. Ask yourself whether the right conversations are happening for the team's commitments to be met.

Thanks Daniel and Ian!

Ian,

For such scenarios where we are already expecting the testing of the user story to be done in next sprint, we mention in Sprint Goal to complete the development activity. So moving testing to next sprint actually does not conflict with the Sprint Goal.

The concern is that the sprint velocity shows the spillover.

Example-

Sprint 1

Sprint goal - Complete development of User Story A 

User Story A - 5 story points (for both development and testing combined)

At the end of the sprint - development completes

Now, the user story A is moved to Sprint 2 as the testing is yet pending

Sprint 1 velocity (Planned, Completed) - 5, 0

Here, the velocity reflects 0 completed as the user story is moved to Sprint 2, which was expected. So although we have met the sprint goal (completing development), the velocity still shows 0 completed 

Is there a better way to calculate the velocity for such scenarios? Please suggest.

Thanks!

Swati Srivastava

There are 2 possibilities, and I am unsure which you are in:

1. No items meet DoD, and you go to Sprint Review with 0 items done

Why is testing not done in the same sprint, what's holding the team from meeting DoD for those items? Or is the Sprint too short, maybe?

There is also the case of the Sprint Goal: can it actually be met if no items meet DoD? You are doing Sprint Review for 2 sprints at the same time, essentially doing a double-length sprint; you are also not planning because you're working on the same items.

... or ...

2. Some items meet DoD, but some items are still in the flow

Is it normal for those items to not be Done? It is possible a developer finishes coding 5 minutes before the Sprint Review, and so that item is not "Done", it goes back to the Product Backlog, and can be picked for a next sprint. That is normal. It would still be interesting to look at why testing is not done in time. (although the 5 minutes example is not repairable)



And then Velocity ... I expect you are calculating velocity for planning. Many people do not like velocity, even for planning. The advice is to use throughput (number of items "done") for planning. But that doesn't change the "0". You could use a moving average to still get a representative number (average velocity for the last x sprints), but even more people oppose an average. but if every sprint has the same spillover, what's the problem? So ... try to get to "done" in the same sprint as much as possible.

In my opinion Story Points should never be used to determine velocity.  They are a guess made at a time where information was limited.  They can be useful for Developers to estimate a Sprint Backlog and their usefulness ends at that point.  There are many forum discussions here that talk about velocity calculations.  My guidance to my teams is to look at throughput, cycle time, and cumulative flow as indicators of delivery and to use aging of work in progress to help manage their work.  For the record, you will not find the word "velocity" in the current version of the Scrum Guide.  

By the way, you have just provided yet one more reason why splitting stories along the lines of QA and Development is a bad idea.  Velocity is about how reliably and consistent you can deliver value.  By planning for the completion of stories to span more than one sprint, you are intentionally delaying value delivery.   Your organization appears to be trying to hide waterfall development practices within Scrum words.  

I pulled this statement from the Scrum Guide's section on Sprint Planning. 

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

If your Sprint Goal states to only complete development work, how is that valuable to the stakeholders?  

These statements comes from the Scrum Guide's section describing the Increment

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. 

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

Sprints are to create 1 or more increments that are presented for discussion at the Sprint Review and delivered to the stakeholders. Those increments must meet the Definition of Done. The Definition of Done indicates the quality measures required for the Product.  So if you are intentionally planning for your stories to span multiple sprints, what do you discuss in your Sprint Reviews where only development work is done?  How can any of the development only Sprints produce any increments? 

I understand that your organization has a process in place that apparently works for them.  But that process is not according to the Scrum framework so it is not Scrum.  Just as you have decided your own way to do work, you can also decide your own way to monitor and manage it.  The answers that we give you based upon the Scrum framework are not likely to be of any use or acceptable to your organization. 

My advice is to talk to your organization leadership.  Ask them what they consider to be a successful outcome of a sprint, keeping in mind that the Sprints are going to be split between coding and testing.  And that final delivery will take a minimum 2 sprints to complete. Ask them how they envision value being assessed. What do they consider to be success measures for teams?  These can help you to determine how to measure the achievements of your teams.  

I wish you luck and hope that you will be able to introduce change to help the organization.  

"Sprint goal - Complete development of User Story A"

I see the way sprint goal is defined need to improved. "completion of development for a story" could be part of DoD not sprint goal. They are 2 different things. Sprint goal is objective of the sprint. It should answer the question "why this sprint is valuable ?" to the stakeholders.

"User Story A - 5 story points (for both development and testing combined)

At the end of the sprint - development completes"

Storypoints are relative estimation considering complexity, uncertainty and size for a story. It is not the sum of efforts that takes to meet DoD. So if a story is not meeting DoD then it can't be counted for velocity.

"we are already expecting the testing of the user story to be done in next sprint"

Your team needs to retrospect on the above scenario to find why they couldn't complete testing in same sprint if it part of DoD(In fact, DoD should have all quality checks included). Did they bite more than they can chew ? You need to find it out.

Thanks everyone for your valuable inputs!