A common misperception is that testers cannot do any work during an iteration until the programmers finish a user story or product backlog item. However, the unit of transfer between programmer and tester can be smaller than the user story. Let’s see how this could work through an example:
Suppose a tester and I are working on the story about auto-incrementing the next check number in a checkbook management system. We would talk before getting started and agree that I’m going to go code the simple scenario where the user enters one check after another and that we’ll force the session to start with check 100. So entering five checks will give 101, 102,…105. The tester goes and writes an automated test for that while I code it. We check that in tomorrow morning and it becomes part of the nightly build. We’ve just exchanged work at a level smaller than the individual user story / product backlog item. Let’s do it again.
Next the tester and I talk and agree that we want to read the last check number from the file storage part of our product. So now our check numbers have to start at the right place rather than always starting with 100. The tester writes the automated tests while I code. We both check in our work and add it to the nightly build.
Next we decide to tackle the situation where the user doesn’t enter one check after another. Instead of check, check, check, check we want to handle sequences like check, check, deposit, EFT, check, deposit, check and make sure the check numbers are incrementing correctly.
Then we decide to handle the case where the user manually types in a check number, overriding the default. Perhaps an analyst figures out what to do in some edge cases around this part of the user story (do we warn the user they’re missing a check? does the sequence start to go off the last entered check number or the highest check number?). While the analyst figures that out the tester is automating and I’m coding. And so it goes….
Tags: teamwork, user stories
This means that pair is of a tester and a programmer. Correct?
Also interested to know what is Analyst doing during a sprint other than writing stories.
I don’t necessarily think of the programmer and tester as a “pair” in the sense of pair programming. They are just working closely together. The example would be the same above if it was one tester (or two) working with two programmers who are doing pair programming.
The analyst is doing anything necessary to complete the work of the sprint. That may involve testing or helping create test plans. It involves some thinking ahead (say 10% of the total effort) about the work coming next. Often analysts will be ScrumMasters on Scrum teams.
[...] In Scrum, Quality Assurance teams are integrated into the Scrum teams. As much or more time is spent testing as coding. At the end of every sprint, we deliver code with zero new defects. That’s something we were never able to accomplish with waterfall processes—or even the RUP. [...]
Hi, this is not a comments, is actually a question: we’ve started working with scrum in December 2011 and it’s not clear to me how the UI guys write their own stories. I mean: we know that we want user stories to be written in a customer-need format, avoiding writing too technical stories with poor value for customers. We also know (and it’s quiet normal) that UI guys use to work 1-sprint in advance, thinking on next-sprint’s interfaces, but also integrating features we’re releasing in the current sprint.
The question is: how do we track the work the UI guys do for the next sprint? it’s not part of the current stories, so, where do I put those tasks?
I hope I’ve been enogh clear
Ciao, Massimo.
Hi Massimo–
I will add this as something to blog about eventually but there’s info on this already in the Succeeding with Agile book. I definitely wouldn’t advocate having UI people one sprint ahead. They can be on the sprint and looking ahead but that’s different than beinga sprint ahead. Lynn Miller and Desiree Sy have written papers on this you can find.
As for tracking tasks, since I advocate them being in the sprint, that’s easy: Track their tasks in the current sprint.
Hi Mike,
thanks a lot for your answer. I read the book you mentioned twice
and I exactly remember that you say that UI and Dev work together toward stories and sprint goal. In addition they also look ahead. It’s a matter of words, but it makes a huge difference. I totally agree.
I just want to know how to write stories for “ahead” tasks, as they don’t have a story in the current sprint. Do you think we could just have a story saying “as a UI designer, I want to story interfaces for upcoming features, so that I can have feedbacks from team members and stakeholders” or something like it?
In any case I’ll have a look at papers you suggest.
Thanks in advance.
Massimo.
You don’t write stories for those tasks. Stories already exist–the stories that will be done in the future sprint. This is a task for that story.