Posts Tagged scrum

Lately I’ve been trying to understand how best to represent Known Unknowns (KU) stories/tasks in the BDC. I’m talking about things like Support cases from customers – things not related to stories from the backlog essentially, that you know you will need to address.

Its the kind of stuff that “is not supposed to happen” as part of the sprint, but we’re in the real world, and in the real world, it happens.

I’m familiar with two major ways to account for those:

  • One is to remove them from the capacity. This removes it from visibility, OTOH it makes for a pure burndown/capacity/velocity calculation/tracking
  • The other is to create stories for those “buckets”. This way you can track them, have better visibility.

Assuming an organization is interested in tracking and measuring this part of the work, the team needs to integrate this into their burndown chart, velocity, etc.

The issue is that those tasks are sort of a “buffer for rainy day”, so the remaining effort on them as the sprint goes by is not necessarily related to actual invested effort compared to the whole bucket, but rather to time left where the events might happen.

Think support cases from customers – assuming you have a 30 day sprint. you planned on 20 days for the sprint based on yesterday’s weather. after 15 days, assuming you spent 5 days on this already, what should be the remaining effort for the BDC?
Naively, 20-5=15 days. But realistically, the statistics are that after half of the sprint, if your yesterday’s weather is to be counted on, 20/2=10.

Is anyone aware of any tools that manage these kinds of KU effectively without requiring the team/SM to manually update the remaining effort?

Together with some other coaches, we raised the option of drawing the planned work as an internal burndown line BELOW the total burndown. Another alternative was to show a burnup of this kind of work separately, so the team has visibility.

The idea is to make sure the team knows whether they got lucky and had more capacity left for their planned work, so should be more aggressive than their original plans, or the other way around. Without this kind of visibility, a critical aspect of the burndown chart is lost – teams don’t trust it, there is too much fog to see clearly where they SHOULD be so they don’t hold themselves accountable to where they ACTUALLY are.

Bonus question – do you have teams that count this work into velocity? using SP? How?

Note that the rationale for counting this into velocity is the “metric” side of velocity, not the planning aspect.

Its clear that this cannot be used to plan the release. It can, if you find the right way to account for it, reflect productivity of the team around this kind of work.

Advertisements

Leave a Comment

Its hard to embrace change…

A key theme in Agile is embracing change. We hear time and again that change is good, we should “welcome change”, yada yada yada. Most teams I see are sick of change. On one hand they are not fully exposed to the business case for change, to the sense of urgency around changing fast. On the other hand, change is HARD for them to absorb.

Effectively embracing change means overcoming the cost of change curve. Traditionally, we were taught that change costs more, the later you learn about it. This is still true. The cost is comprised of the complexity of dealing with change when it is buried under layers of work that was done since the original development was finished.

In many systems the quality of the codebase makes it even harder – spaghetti code, copy pasting, and a bunch of other smells / technical debt aspects make time work against us.

So how can Agile Engineering practices help us deal with change?

First, since we anticipate anything can change, its important to avoid wasting work in areas which might change.

In general its important to do as much of our work “just in time”, avoiding the planning ahead that is based on wishful thinking about how the future will look. The XP principle of “Simple Design” helps us provide the simplest solution that can possibly work. Complexity and “Fully Featured flexible solutions” are our enemy here. We have no way to know that they will actually be used since we cannot really predict the path the system will take. You Ain’t going to need it – YAGNI is another key XP phrase.

We also need to keep our systems at very high codebase quality to minimize the cost of changing when it does happen. Refactoring as part of the ongoing development cycle helps us achieve a Sustainable Pace where we might pay an ongoing small price, in order to be ready for whatever curve ball change throws at us. Think of exercising in order to keep our body healthy and able to cope with whatever life throws at us…

The air force uses AWACS planes and other types long range radars to get early warning.

In agile we use iterations, TDD and CI.

Iterations are a key factor here. Since we get feedback after every iteration we hear about required changes earlier, as well as discover many defects due to the testing we do in order to achieve PSP. This much can be achieved without any special engineering practices.

Test-driven Development provides much earlier feedback about the behaviour of our units, modules and systems, and makes sure that our system is REALLY Designed to meet its specification.

Continuous Integration provides early warning for any integration issues, avoiding any form of “Big Bang” integration problems.

Once we do need to make a change, we rely on a high quality codebase, as well as several safety nets, in order to proceed quickly.

If we use ongoing Refactoring, applied the relevant Design Patterns, kept the design as simple as possible, the cost of making the change will be as low as it can be. Once we implement the change, Continuous Integration, together with the test suite we accumulate using TDD, will catch any problem we create very quickly. Weeks of regression testing, or Dev/QA managers losing sleep over a risk-taking testing coverage, will thankfully become a part of our past problem.

Next in the series – how fast iterations strain the typical team starting with agile…

Leave a Comment

Agilesparks Agile VP R&D forum

Welcome to a new blog for Agilesparks, our Agile/Scrum solutions company.
On last Thu, we had the opportunity to present Agile/Scrum to a group of R&D leaders from various companies/organizations in Israel.

Danko provided his signature exciting intro to Agile, followed up by a customer success story, an intro to Engineering practices delivered by yours truly, a discussion of Agile Metrics and Measurements, and a Q&A panel.

Based on initial feedback we got it seems like we got people quite interested in what Agile/Scrum can provide…

If you would like to hear about Agile/Scrum we have similar opportunities coming up. Check http://www.agilesparks.com for more details.

At the meantime, checkout my presentation:

and some pictures from the event:

see you!

Leave a Comment