Posts Tagged ‘Story Pointing’
Poker Plan With QA … Part 2
I wanted to post this as an update to the original post on how to estimate story points using the poker planning technique and involving your QA team.
In the first post I describe how a poker planning session almost broke down when including the Quality Assurers in estimating the relative size of each of our stories. Just to get through that session we ended up producing one or two estimates that didn’t include the testing time.
It’s amazing how adaptable people can be. On our second attempt, only 2 weeks later, I’m very pleased to say our session went brilliantly. They key to this success, I feel was down to the ScrumMaster. They took the initiative, pre-empting another possible disastrous session and clarified some of our own rules.
Last time, because both engineering and QA were unused to thinking about delivering stories to done including each other’s time, we ended up settling on the highest value either the engineers, or QA, or a hybrid could agree on. There was very little unanimity, nor was anyone really convinced we were providing estimates to the best of our ability.
This time we started our session by reviewing a very simple process designed for our team that the ScrumMaster had put together. If consensus could not be reached by the first attempt at laying cards, try again. If still no consensus after a round of discussion, try again. On the third attempt if there was still no consensus we would settle on the highest value, as we had in the previous session. Mike Cohn suggests in his “Agile Estimating and Planning” book to “…continue the process as long as estimates are moving closer together…”, but in the past this hasn’t worked for us hence the 3 time cap.
From there on in, the team set about story pointing. We had about 9 stories to estimate and in about an hour and a half we were done. Estimating for each other’s disciplines still didn’t come easy for everyone, but when someone struggled, the team worked with them so they could understand what they were thinking about. Only once did we not reach a consensus by the third attempt, and that story had such a high estimation it would need to be broken down further. The mood of the session was very positive leaving all present extremely satisfied with the result.
So, the first stage particular exercise to incorporate QA into our story point estimation sessions has been a success. Yet another leap forward in our journey.
There will be more to follow on sprint planning with QA and integrating the seating plan of teams who are already co-located.
Good stuff.
Poker Plan With QA
Previously in our sprints we included QA time by adding a buffer to the engineer’s task estimates. From now on, to provide greater visibility of the challenges QA might face whilst testing each story, we have started to include them in both the story point estimating and tasking sessions.
We started out by suggesting that the team (QA and Engineering) collectively estimate a story point value not only for how long it takes to engineer, but also how long it may take to test (relative to another of course).
This didn’t go as expected.
Some members got it and were able to take into account the advice or suggestions from their peers and re-evaluate accordingly. Others found it very difficult to accept how QA and engineering could effectively estimate each other’s time.
Such reservations were confirmed during the estimation of the second story. The engineers agreed a 5, QA initially put down a 1. The engineers then suggested to QA what might be involved in the story, but QA re-evaluated only a 2. This resulted in a lively debate about what we were doing, how “pointless” this all was, etc, etc and the session pretty much broke down.
The strongest opinion of what to do next was for the engineers to story point their value, QA to story point their value and then add the two together. For the sake of moving on we tried it. We went back to the first story, engineers a 2, QA a 1 so we got 3. Fine. Next, engineers 5, QA 3 and we have 8. This is easy! Story 3: engineers re-evaluate a bit between 13 and 20 but settled on 20, QA 5. Ok, so we suggest either re-evaluating again collectively to see if we accept 20, or we round up to 40. Nope. Some of the engineers wanted to stick with the story point value of 25 and the previous debate flared up again.
Both engineers and QA understand why we story point; that we use the Fibonacci sequence to balance out the estimations. They’d heard the bucket of water metaphor Mike Cohn used during my ScrumMaster certification ”… you have 25 litres of water, that’s not going to fit in a 20 litre bucket, you should use a 40″. They want (and agree with the need) to be more integrated, but just struggled with the concept of collectively settling on a figure. There was alot of confusion over the level of accuracy required.
After a lo————ng debate, to get through the session a consensus was reached. In order to obtain our team velocity we just needed to be consistent over time. The team settled on this: QA story point their value, engineer’s their value and to accept the highest. From that point the session finished quite quickly; everyone was a bit frazzled but content with the result.
What we have done is wrong. Settling on the highest value is fine if QA vote 1 and engineers vote 13. But what if engineers vote 13 and QA vote 8? Or QA vote 20 and engineers vote 13? The real estimates for those last two examples would surely be nearer 20 and 40? We are not providing an accurate estimate to the best of our knowledge at the time. This is important for management to plan a release. It’s difficult to accurately estimate for a long release period, but we should not knowingly underestimate. This will need to be addressed again during the next session.
The goal is that the team will naturally start considering each other during estimating sessions. They will get there. Even the senior engineer who raised the most questions about the process at one point put down a 40 and justified it by saying “well there’s a lot to test”.
We have just started with test automation which will help to bring QA and engineering together further. We might also get there more quickly with smaller teams; yesterday’s was 3 QA and 7 engineers.
The positives from the story pointing session? We can now clearly see the different challenges that QA face from story to story, which sometimes do not have a direct correlation with engineering time for the story. This is definitely going to help us with both planning and execution.
