1

During a sprint, producing frequent builds, conducting testing, and fixing bugs quickly during an iteration can become daunting, especially when the quality of the work done is not optimum. So how can a product owner or scrum master best manage the reoccurring fixes during a sprint?

  • This raises a number of contextual questions. Why is the PO or Scrum Master "managing fixes?" Why is this not work that the Development Team or Scrum Team as a whole are self-managing? Why isn't sub-optimum quality being addressed through your Definition of Done and Sprint Retrospectives? – Todd A. Jacobs Aug 17 at 20:15
  • The PO or Scrum master is not managing the fixes, but more concerned with the negative impact on the sprint timeline, the issues being faced by the dev team were communicated as such. – Judith Aug 17 at 20:19
  • What "Sprint timeline?" What's the Sprint Goal? What's putting the Sprint Goal at risk? What issues is the Dev Team facing? Why aren't they empowered to fix it? – Todd A. Jacobs Aug 17 at 20:31
  • A 2-week sprint, sprint goal is to build new features, the dev team are not experienced enough to handle set tasks, the budget was lean, so the company opted for cheap labour and it is now impacting the quality and time delivery of the project. – Judith Aug 18 at 7:04
  • 2
    "build features" is not a sprint goal, it's a cop-out to not have to think about what's actually important ;) – Erik Aug 19 at 12:34
2

In Scrum, the Product Owner has limited power to improve quality. I see 2 potential actions:

  1. Manage the Product Backlog accordingly. If the timeline is too tight, try to find items which can be potentially removed or replaced by a simpler but sufficient solution.
  2. Write more accurate user stories and acceptance criteria. While the tumb-rule suggests not to do elaborate upfront specification, difficult topics and junior teams may do with more details and some guidance. If team members are really beginners, backlog refinement can be used for education.

The Scrum Master can also help in 2 areas:

  1. Knowing past performance, help the team better estimate their work. This will not make the delivery faster but more predictable.
  2. Underline the importance of quality checks at all steps of the process. For juniors, even such simple ideas may help such as
  • use an IDE which has a static analyser,
  • follow code conventions,
  • perform unit testing,
  • ask for clarification if the backlog item is not clear,
  • raise problems as soon as they are found,
  • refine the definition of "Done" with the team,
  • ...

If delivery by due date seems to impossible with the team, escalation is also on the table. The management may decide to give more time/budget/people. Or help to reduce the scope.

| improve this answer | |
1

especially when the quality of the work done is not optimum

This is the area I would focus on. Raise quality and the impact of testing is reduced.

Things like test automation and continuous integration can really help.

So how can a product owner or scrum master best manage the reoccurring fixes during a sprint?

I'm assuming you are using the Scrum framework, in which case neither the Product Owner nor the Scrum Master is involved in managing recurring fixes. This is the responsibility of the development team.

However, it would certainly make sense for the Scrum Master (and perhaps the Product Owner) to raise concerns over quality standards during the team retrospective.

| improve this answer | |
1

especially when the quality of the work done is not optimum.

How do you measure the quality of work ? "Optimum" is ambiguous in my opinion.

Do you have DoD defined for the work/stories/fixes ?

So how can a product owner or scrum master best manage the reoccurring fixes during a sprint?

If you feel that recurring fixes are happening due to obvious issues during story verification then you could include "unit testing" and "End to End testing with db verification if needed" in your DoD.

As you gain more experience, improve your DoD to be crystal clear for Devs.

| improve this answer | |
0

A little e-book that I've never seen in print, called Managing the Mechanism, made the important point that computer software is actually "an autonomous, self-directing machine." The team that built it has no influence upon it when it runs. Either the machine is built "completely and correctly," or it will fail – there are no in-betweens.

So – if development quality is as you delicately describe it ... "the task is Not Done." You should push very hard for test-driven development where a feature is accepted as "done" only when it passes an automated and re-runnable test, which will be continuously run from now into the future. Developers are responsible not only for preparing (and reviewing) the code, but also the test.

For instance, in the Perl programming language, anytime and every time you install a third-party package, extensive tests which are part of that package are run on your system. If any of those tests fail, the package will not install. This is why you can have confidence that the package will work as promised, on your system. The same concepts (and, the same tools) can be applied to any software system built with any language(s). It just requires "team self-discipline." No, you don't have to live with "the 80/20 rule."

Importantly, this regimen will also immediately detect when something apparently-unrelated "broke the build." Because the software machine is composed of literally millions of moving parts, all potentially interconnected, all with the ability to negatively influence anything else in the system. And, you won't know it unless you are constantly (and mechanically) looking for trouble.

"It doesn't matter how fast you build junk – it's still junk." And, because of the peculiar nature of "software is a self-directing machine," that standard is and has to be very unforgiving.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.