have 2 week sprints with 1 week qa sprints become somewhat standard @ large scrum shops?

[dotnetguy]

Have 2 week sprints with 1 week qa sprints become standard @ large scrum shops these days? The large shops I've worked at over the last few years have used this structure. It seems to work a lot better than trying to shoehorn everything into 2-week sprints in my experience.

[Markus Gaertner]

No, they haven't based upon what I've seen.

Best

Markus

Save our Scrum: http://leanpub.com/saveourscrum

-- 

Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

On Fri, Jul 29, 2016 at 12:06 AM, dotnetguy <andrew.d....@gmail.com> wrote:

Have 2 week sprints with 1 week qa sprints become standard @ large scrum shops these days?  The large shops I've worked at over the last few years have used this structure.  It seems to work a lot better than trying to shoehorn everything into 2-week sprints in my experience.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Ron Jeffries]

Does the Scrum Guide clearly state that the end result of EVERY Sprint is an increment of fully tested, integrated code, containing all the backlog items from the beginning of the project up to and including those from the current Sprint?

Yes, it does clearly state that.

On Jul 29, 2016, at 12:06 AM, dotnetguy <andrew.d....@gmail.com> wrote:

Have 2 week sprints with 1 week qa sprints become standard @ large scrum shops these days?  The large shops I've worked at over the last few years have used this structure.  It seems to work a lot better than trying to shoehorn everything into 2-week sprints in my experience.

Does the Scrum Guide clearly state that the team takes on the amount of work that they can complete within the Sprint?

Yes, it does clearly state that.

So ... how is this "shoehorning" coming about, exactly? How is this untested code coming about, exactly?

Ron Jeffries

[Andy Watkins]

Andrew, 

I agree with Ron; you're doing it wrong.

It's true that, if you have QA specialists in your Scrum Team, they can't test a specific feature on day 1 of your sprint; but I bet there's a load of other stuff they can be doing, like working out how to "blackbox" test it, working with the developer who's implementing the feature to gain understanding in how to test it (and see what unit tests the developer is writing so as to remove duplication). Or working on a different feature.

Maybe you need to think differently about breaking down stories, so your QA specialists have things to do early in the sprint that can add business value (I bet there are missing tests that need writing), 

Note I've not called them "testers", because you're all one, self-organising team, right? 

They should be "T" shaped people (look it up) and might want to have a go at coding, or helping software engineers to think like testers by pair programming. 

If your testers are doing lots of manual testing, consider whether you need to encourage them to automate these tasks, so they can do deeper testing that cannot be easily automated.

In a team I worked in, it took us a long time (~6 months IIRC) to align Dev and QA into a single sprint. It's hard, but it is possible. We had QA running one sprint behind for a while, but that wasn't good enough.

I think you've got a topic for your next retrospective: ask the team how they think it should be improved.

Hope that helps

Andy Watkins

--

[Roger Brown]

If it takes 3 sprints to actually get to "done", no one knows if it is correct until 6 weeks have passed. The customer gets nothing for that long. The risk of re-work piles up and the cost of the re-work goes up. Don't test later; reduce sprint scope to the amount the team can actually get done. In the long run, more will be delivered. 

Here are some more ideas on how and why to do this: http://www.agilecoachjournal.com/2014-02-03/a-sprint-is-not-a-2-week-waterfall

- Roger Brown

[George Dinwiddie]

No, the government agency I'm currently coaching has a large program
working two-week sprints and pushing to production twice a week. They
have things they can improve, but don't need an offset testing sprint
which, IME, creates more problems than it solves.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Punita Dave]

If the company has adopted Agile mindset, no matter how large the shop, teams finish what they take up in the Sprint. QA sprints are an indication of other bigger problems - technical debt, culture, product architecture, etc.

Some very large scale shops (5000+) that have multiple independent products, that eventually talk to each other, sometimes resort to large product integration testing. This is independent of each product's QA and release. Each product in itself runs 2-week Sprints and releases independently.  

[Nigel Baker]

I am seeing this (Dev sprint then QA sprint) very little/never these days in the UK. It's becoming (in my circles) so uncommon, that the last couple of times I made jokes about it, people didn't really get it. They hadn't seen it and it was obviously silly. 

I used to get a LOT of nervous laughs about it (2+ years) ago.

I am UK based. YMMV.

Nigel