Skip to main content

Sprint plus one Agile model

Last post 03:34 pm August 7, 2018 by Tim M
4 replies
11:59 am August 3, 2018

Hi All,

I would like to know if there are any references for "Sprint Plus One"  Agile model.

We are currently following this model, where we have multiple Feature scrum teams and one System scrum team. System scrum team tests the features developed and unit tested by Feature team from the previous sprint. If Feature team delivers Feature - X1 in Sprint2, System team tests this feature in Sprint3.

Also is someone else using this model? If so, can you share your positive experiences and your challenges faced in this?

 

Thanks in advance,

Prakash

 


05:37 pm August 3, 2018

We are currently following this model, where we have multiple Feature scrum teams and one System scrum team. System scrum team tests the features developed and unit tested by Feature team from the previous sprint

In Scrum each Sprint must yield a potentially releasable increment, with no work left undone, and the Definition of Done must be fit for release purposes. In your case, how are the increments produced by feature teams at the end of each Sprint assured to be of release quality?


02:21 pm August 6, 2018

I am familiar with this and I don't really like it. But that is the beauty of Agile you can come up with your own techniques.

I am a big advocate of testing as part of DOD so I’d be interested on what your test strategy is. Sprint 3 is really a test sprint from what I am reading.

At 1st I thought you were saying you had feature and component teams but now I am reading it different. Your system test teams just sounds like a QA team?

 I don’t think from what I can tell you’d be doing any automated testing you are doing manual testing?

If it is working, then stick to it but my end comment is I don’t like it. Scrum master don’t run QA though.


03:30 pm August 7, 2018

I'm all for trying new things but this model seems to run against the very ethos of scrum and agile.

Delivery value early and often and maintaining working releasable software is why agile exists.

If we defer testing to a later sprint how can we say it's done?  We don't have releasable software until we've reached the end of the multi-sprint cycle.  We are testing in big batches which increases the risk of finding, or even worse, not finding defects.  We are building new features on top of untested work, and fixing bugs found in testing sprint will have an impact on the new work being developed.

Is this a sticking plaster for a lack of test automation?  Solve that and you won't need this and can start to reap the benefits of an agile approach.


03:34 pm August 7, 2018

+1 Steven


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.