Scrum/Agile: How do you plan in internal improvements? [closed]

Question

I have now worked on two different teams that use the Agile/Scrum approach in the last two years and both teams were eager to improve the way they approach software development. In the first team, we could easily convince our product owner to get time for internal things like improving the build system, setting up better integration tests, having a better release strategy etc. Right now the PO is also willing to give us time, but he is more pushing back, which is reasonable as he also must get his things done.

Anyway my question is now, how do other teams handle this? Do you create an improvement story and put it on the table during planning or do you keep a "bucket" of time around for such things? How difficult is it in your experience to convince the product owner to do get time for improving? After all these kind of improvements will benefit the team, but not directly or immediately the prodcut owner/business.

Answer 1

Great question. I think there are several flavors of "action items" from retrospectives that deserve different approaches.

1) technical tasks to address things like technical debt or infrastructure improvements - like "We should ensure we have no database calls in the view layer of our application, cuz that caused us to waste time in this past iteration... somebody should do a search through the code to make sure we're not doing that someplace else."

2) process improvements (e.g. "folks aren't coming to the standups on time... lets start a $1 for charity donation whenever someone's late".)

The first category can be significant work, or it might be straightforward. The example I showed was pretty easy... but might generate other tasks that need to be scheduled (e.g. removing the database calls in the 5 locations where they were discovered).

The second category should be handled/driven by the iteration manager, project manager, scrum manager, etc. I (as a Scrum Master or Project Manager) usually list them on a project wiki and talk about them in retrospectives, check them off when they're addressed, and report to the team on status. I keep the fire lit.

I think the mistake in the first category - technical tasks - is that we don't define acceptance criteria. Your examples included "improving the build system, setting up better integration tests, having a better release strategy". These are non-deterministic and need to be enumerated in crisp terms (using spikes if necessary). So - improving the build system might start with a technical task or a spike to assess options.

We also need to break-down and prioritize technical tasks (e.g. maybe "better integration tests" could start with a technical task of defining the current integration coverage, or assessing the percentage of bugs that could be blamed on integration failures to build the case for investment there.

Once you have your priorities set, then you can convey the value of the high priority items and negotiate with the product owner for time to spend on them. I'm not a big fan of predefined buckets to spend on anything... but having the conversation with the product owner with crisp requirements, ROI, and acceptance criteria is key.

Answer 2

Improvements should be part of the sprint the same way new features are. It is up to the team to demonstrate to the Product Owner that those improvements are necessary for the upcoming sprint. This may slow down the rate at which new features are produced but it is useful for the product in the end.

On the other hand, I have issues with sprints that only contain improvements. Every sprint should produce output that can be demonstrated to the Product Owner.