Sprint plus one Agile model
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
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?
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.
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.
+1 Steven