Work in progress (WIP) in Scrum

Let me tell you a story, about how important is focus (a core value of Scrum) and how work in progress (WIP) affects it. Two scrum teams were working once. Team A and team B. All were motivated, good, smart, had equally good product owner with equally INVEST user stories.
They both want to do a great work, while enjoying, providing their expertise, growing together, a dream made true

The first day of the sprint team A did a nice daily where everyone knew what the priority was. Started targeting the most important user stories. Story 1 for instance. At first there were some dependencies, like api calls, designs, whatever, but it doesn’t matter team A worked as much as they could in the first story 1 using mockup objects, building dummy screens, faking apis and so on. Whenever a dependency is met, the team integrates or team can analyse and changes follow just-in-time. After a working day, they had story 1 ready to integrate, the most important ready to send to QA. They did send that to QA and went for a coffee. QA found out misunderstandings so went back to the team to reopen story 1 with feedback. The misunderstanding was no big deal so they fixed it and sent it to QA. QA found bugs, so the story one was reopened. Luckily they had now a couple of automated tests (sadly they were not using TDD). Every one was in the right branch, every one had the editor opened, a couple of hours of pair programming fixed all the bugs. It took too much time to close story 1, double of what was estimated but finally was merged. The kept on with next most important story, same way, trying to close it effectively without bugs. Meantime QA was automating story 1. As a result after the sprint, only 50% of the sprint backlog was finished and released to production. The other stories along with some new important ones went to the next sprint.

Team B on the other hand opened 2 stories, story 1 and story 2. Started working on both. While some dependency kicked they would change branch and context. The dependencies doubled, because now we need two designs and two apis, as usual handing out an api or design leads to more questions, changes, feedback loop… at some point both stories were sent to QA. QA was a bit of a bottleneck for a few minutes. Just after sending the stories to QA, the team opened other two stories, 3, 4 in new branches and started working. Shortly after, QA found out errors related to the interpretation of the QA in story 1. Reported back, but everyone was busy so QA wrote that on a document. Regarding the team, some kept on working in the new stories, some other reopened the old stories and started changing branch and working. The other story was ok regarding acceptance criteria but had bugs, reported. By then there were four stories, a document for the bugs, four branches and a lot of stressed developers seeing that the time was running. The end of the sprint the general mood was horrible. Team was working overtime, stressed, PO worried and losing trust, QA was upset and the final outcome of the sprint was a high number of buggy stuff the PO was unsure to deploy. The PO planned a “re-do” sprint taking the bugs as reference, sprint retrospective was a war, as frustrating as the sprint review.

Who will be fitter, happier, more productive in the long term? And I am not talking about limiting the work in progress to one story, it is an example

What happened to the team of case B? At first it seemed they were going “faster” -the illusion of productivity– but their path was unsustainable. Shortly after they were eaten by doubts. By mid sprint the chaos was total, nobody was sure of the status of the stories or what to do about them to complete them. This is a consequence of a low focus

Some causes and effects of a low focus (yes a core value!) with lots of context change

– Development overhead, change branch, scheme, etc
– Documents had to be read, controlled, maintained
– Horizontal dependencies were flooded (and blamed)
– QA was not focused so missed important stuff
– Feeling of doing over and over the same things (second sprint)
– At the beginning of sprint, apparently working faster that estimated
– Shortly after beginning, working much slower
– End of sprint, stressful madness
– For the product, no real increment until the sprint were they fixed all the bugs
– No possibility to react to changes
– Bad team building, hard retrospective, effects of the failure feeling
– Lack of confidence for next sprints
– Stress/mood/blaming/excuses
– A lot of horizontal slicing while vertical slicing is the value
– Working more to get worse results

 

Scrum roles and users

Last week I was reading some material on scrum, particularly on agile requirements acquisition for a post I plan to publish soon. I was reviewing the User Stories Applied For Agile Software Development book by Mike Cohn, definitively a recommended reading. 183072549

I like the Capt. Obvious facts about software development and how often we need someone to constantly remind our teams about those allegedly obvious statements. This is precisely the case, do you ever forget to target your efforts to what the user demands? I am sure you do, I also do

Writing user stories is the way to formalize requirements in some agile methodologies as scrum, the well-known formula As a role, I want goal/desire so that benefit. This definition itself forces us to think in the user roles and pushes us to go for a genuinely user-driven development

Read more →