How does QA fit in?

Liz! asked a question.  She and her team are starting agile and she can't get much info on where QA fits into to Agile.

First, I want to reiterate Jeff Sutherland's concern, that he biggest problem is that too many teams are not getting to working product (working software) within a Sprint (a 1 to 4 week consistent timebox).

In my view, the absolute minimum Definition of Done for a typical software "story" or PBI (product backlog item) is:
* requirement defined
* coded
* unit tested
* functionally tested (aka acceptance tested)
* all identified bugs fixed
* reviewed by the Product Owner, and all 'problems' fixed

This is the minimum definition, assuming one starts with significant impediments.  The ideal definition includes live, in production, being actively used by the customers with normal volume.

Now, let's add a key principle: The bad news does not get better with age.  In other words, it is much cheaper to slow down and test and fix now (even though it does have some cost) than to not test in the Sprint and discover the bad news later (where the price is much higher).

So, our answer is that good professional testers must be in the Scrum team.  Ideally that means 100% allocated to one team.  At a minimum, 50% allocated to one Scrum team.

Where does QA fit in?  Well, usually the testers are aka QA people.  Sometimes QA means truly "quality assurance" per se, in which case the QA people look at the Scrum team (and the process elsewhere as well) to see if sufficient quality is being baked in in the best possible way.

Liz, we are also asking that coders help testers, and vice versa.  And each side no longer looks at the other side as an enemy.  Still, the testers are always trying to "break it."  So, they maintain that attitude.  And each coder views any break identified now as a 'win' for the team, not as a loss for his ego.

Also, usually in large firms that is a 'landing strip'.  By which we mean some final testing where the code of say 3 teams comes together into one stream.  And is 'finally' tested.

A common pattern is that a 'test scrum team' does the final testing, and sends bugs back to the 'development' teams.  Obviously, QA people populate most of the test scrum team.   -- This is a common pattern when you have lots of impediments; and not a bad pattern in that situation.

So, Liz!, have I answered your question?
(There are other situations and complexities that might be addressed, but I wanted to hit just the highlights.)

Release Planning - Business Value Points

One thing different about what I recommend for Release Planning and what others recommend is Business Value points.

What do we mean?

First, is it useful to distinguish the Business Value (BV) of items in the Product Backlog?  YES!

Why?  Well, Pareto says that you can re-apply the Pareto rule (the 80-20 rule) at every level of the population.  That means the rule of the "vital few" also applies to things "in the small".  We have to focus on the gold, the platinum, the diamonds, and ignore the silver, the copper, the dirt.

Also, it is very helpful to put numbers on the items.  Numbers are clarifying.  "Oh, 5 times more important? Well, in that case... Before I thought it was just a little bit more important."  It is useful to explain why something is important, but also useful to make it specific with a number.

A number does not magically make BV less complex.  There are myriad things going on, and changing with BV.  There is the MMFS (minimum marketable feature set), there are inter-relationships.  There is quality and beauty, etc, etc, etc.  If we find things have changed enough, we can easily change the BV points (BVP) number.

Now, the most valuable thing about using BVP is not that we end up with numbers on each item.  The most valuable thing is the discussion amongst the team and the business stakeholders.

OK, how do we do it?

First, discuss the 2-5 main drivers of BV.  My hypothesis is that each project or product could talk about these drivers in a different way.  So, get the business stakeholders and the full Scrum team together, and discuss and agree on the main drivers.

Then, pick your 5 best experts on Business Value (really from 4 to 7). Ideally people who will see different parts of BV (I am picturing 6 blind men and an elephant just now).  Typically these people are the Product Owner, and 4 business stakeholders (including maybe a real user or end user!).

Then pick the single item with the most Business Value.  Make sure it is not what I call a super-epic (the epic that almost describes the whole project).  It needs to be a reasonably small epic.

Call that "the highest number".  Say, a 130 on my scale above.  Or if you are using regular planning poker cards, a 90 or 100.

Then get the Fibonacci cards out.  Ideally real Fibonacci cards (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144). 

Then take User Story cards randomly, and compare them.  Then the rules are just like Planning Poker, except that you are voting "how much smaller is this new story compared to the reference story?"  If the reference story is 90, and the average for the new story is 30, that means it is 1/3 as important as the reference story.

We strongly recommend averaging once the "experts" get to within 3 consecutive Fibonacci cards of each other (a degree of consensus).  Averaging leads to a better resulting number.

The implementors listen to the experts discussing and voting on BV.  They learn.  If they have questions, they ask.  (Part of the purpose is to move the tacit knowledge of business value, of why we are doing this work, into their heads and hearts.)  But the implementors cannot sidetrack the conversation.

After the team of experts has voted on all the user stories (PBIs), then the team looks over the whole set.  Are any of them looking stupid now?  If so, re-vote.

BVP can be re-estimated later, whenever we think we are smarter (or identify that we were stupid).  They should happen fairly often.  Understanding BV is really hard!

Latest Reading List - Books

We have a list of recommended books at LeanAgileTraining.com, here.

In addition, we can recommend the following:

A Sense of Urgency by John Kotter

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising.

Toyota Production System by Taiichi Ohno.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)by Frederick Brooks.

Fit for Developing Software: Framework for Integrated Tests (Robert C. Martin Series)by Mugridge and Cunningham.

Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series)by Duvall, Matyas, and Glover.

Agile Retrospectives: Making Good Teams Greatby Esther Derby and Diana Larsen.

Lean Software Development: An Agile Toolkit (Agile Software Development Series)by Mary & Tom Poppendieck.

Project Retrospectives: A Handbook for Team Reviewsby Norman Kerth.

Test Driven Development: By Example (Addison-Wesley Signature Series)by Kent Beck.

The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials)by Katzenbach & Smith.

Working Effectively with Legacy Code (Robert C. Martin Series)by Michael Feathers.

The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovationby Nonaka and Takeuchi.

Good to Great: Why Some Companies Make the Leap... and Others Don'tby Jim Collins.

Software by Numbers: Low-Risk, High-Return Developmentby Mark Denne and Jane Cleland-Huang.

Agile Estimating and Planning (Robert C. Martin Series)by Mike Cohn.

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series)by Mike Cohn.

Implementing Lean Software Development: From Concept to Cash (Addison-Wesley Signature Series)by Mary & Tom Poppendieck.

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni.

Comment: I have given links to Amazon, which has some benefits. I am slightly concerned that it may appear too commercial. There is certainly no obligation to buy from Amazon.

Suggestion: Some of these books are technical (in one area or another) and some are more about people. Mix and match. Consider what you need to learn. Consider what you are most ready to learn. And don't think too much in the sky. See how much you have really learned by putting your ideas into action.