Tag Archive: scrum


Scrum and tech debt

A Scrum Alliance article has this to say about tech debt and how to manage it in the Scrum workflow

Servicing the technical debt
The first step in servicing the debt is to identify any such issues and register them — making the debt visible for the team. These could be made part of the product backlog or even be part of a separate technical debt backlog for purposes of tracking. The team can then evaluate and prioritize, taking into account the effort required and the “pain” caused by the technical debt and its frequency. The product owner would need to make a conscious decision whether the “economics” justifies the cost of the technical debt. It has to be kept in mind that not all technical debt need be repaid; e.g., one can live with issues relating to a product nearing its end of its life. However, it is important during this time that technical debt is not accumulated, since that would only cripple the system

From David Hawks, CEO of Agile Velocity, who sums it up like this

In the sprint I believe all work should be made visible. I probably wouldn’t put points on it since it isn’t part of the release plan. Also I encourage folks to track a separate tech debt backlog to make that backlog of work visible and prioritized

In other words, the Product Backlog should still only be populated with user stories, and user stories should always be testable and estimable, but you also want a Tech Debt Backlog populated with tech debt stories that aren’t necessarily testable or estimable. This separate Tech Debt Backlog makes it clear to the testers that this isn’t something they need to test, and it’s a useful way of capturing work that might normally be a spike time box or just skunkworked outside the workflow.

See more

We’ll ask for estimates and make them deadlines

We'll ask for estimates and then treat them as deadlines - We'll ask for estimates and then treat them as deadlines  Dr Evil and minions

Scrum Backlog Grooming

Scrum doesn’t have an explicit prescription for backlog grooming, but those of us who’ve practiced Scrum know that it’s needed. ┬áThis video illustrates some scenarios that come up in grooming sessions and has answers in useful language other than “No”.

Scrum in one page

Here is the Scrum agile method summarized in one page:

How the Scrum method works:

  • There is one Product Owner (e.g. a business analyst) for each project and he/she creates a prioritized wish list called a Product Backlog.

    • The backlog is an ordered list where the most urgent item is #1, the second most urgent item is #2, etc.

    • The Product Owner is the only person who can change the priority of items in the Product Backlog.

  • During Sprint Planning, the team (i.e. developers, testers, and dbas) pulls a small chunk from the top of that wish list (i.e. the most urgent items) and decides how to implement those pieces.

    • This chunk of the Product Backlog is called the Sprint Backlog.

  • The team has a fixed amount of time, a Sprint, to complete its work (usually two to four weeks) and meets each day to assess its progress (daily scrum).

  • During the sprint, the Scrum Master keeps the team focused on its goal and removes impediments to productivity.

  • During the sprint, the Product Owner can change priorities in the Product Backlog, but cannot change priorities to the Sprint Backlog.

    • The Product Owner is the go-to person for the team to get clarification on functionality or usability.

  • At the end of each sprint, the work should be code-complete, tested, and ready to deploy to prod.

    • Items not completed are put back into the Product Backlog, to be finished in a later sprint.

    • Therefore the sprint deadline is never extended to finish items or for any other reason.

  • The sprint ends with a Sprint Review and Retrospective

    • Sprint Review is where the sprint’s progress is demoed and discussed with the product owner (and ideally, the customer).

    • Sprint Retrospective is where the team discusses ways to improve productivity and eliminate pain.

      • Rule #1 of the retrospective is that no person or part of the organization is allowed to be blamed for problems. Processes allow people or parts of the organization to be inefficient, therefore the discussion focuses on how processes can be changed to improve the situation or remove impediments.

      • The best improvements are taken from the retrospective and implemented in the next sprint.

  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

  • The cycle repeats until enough items in the product backlog have been completed for a prod release or a deadline arrives. However, work can be stopped at anytime and finished items can be deployed to prod in a short amount of time in a fully workable and tested state.

(This is a summary of the Scrum Framework in 30 Seconds – yes, a summary of a summary)

© 2017 Robert Corvus