Prioritizing a backlog with multi-attribute utility analysis (MAUA)

One of the most important things a product owner should do is to prioritize. What should we do now? Where should we put all our efforts, money and brains?. Inside a product team there are internal and external inputs that vary from opportunities, experiments and outcomes to risks, debts or defects. While different sub-teams can come up with a number of features or stories that come out of specific artefacts like dependency graphs, user story maps or metric optimization items, with enough amount of inputs the putting-all-together backlog can be hard to prioritize. If I have framed your situation please keep reading.

Read more →

 

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

 

Dividing scrum user stories into dummy tasks is evil

One of the keypoints of the scrum sprint planning meeting is the division of the user stories into tasks

  • it leaves less questions unclear to anyone, by dividing you find out more about the task
  • it helps provide better estimations
  • it gives all the team the same understanding of the user story scope, affecting at the sprint scope
  • it allows a better parallel work to happen, particularly on highly vertically specialized teams
  • team does it, team adapts it to the way to work (TDD, design mockups…)
  • the stories come up with their own roadmap which also serves as feedback for the PO
  • … I could add more stuff here

At the same time sprint planning meetings are considered a nightmare by some teams (quite hard yep). Earlier than later someone comes up with some sort of copy & paste candidate of a generic list of tasks as a solution to make the meeting lighter, for example

Read more →