Scrum: Should Irregular Events Be Estimated?

Question

Should a Scrum team estimate irregular, planned events, such as an overview/demo to new users and potential customers? Our team is pretty small, so the effort to prepare for and conduct these events falls on us (primarily the Product Owner, Test Lead, and Scrum Master). We've even had our entire team there for parts of them, taking notes on user interaction and feedback.

As the Scrum Master, I believe these meetings are overhead and should not be estimated. They don't directly add value to the software -- their primary artifact is the generation of new backlog stories and the identification of interested customers. However, the team disagrees with me, since they are understandably putting good effort into these events. In my opinion, the bigger issue is that our team members are responsible for coordinating and in a way participating in these events. They should be shielded from these tasks, and I don't believe we should compromise simply because there's no else to do it.

Thanks for your input.

Answer 1

Consider the extremes: if your team spends 4 weeks setting up for a 30 minute demo, something is clearly amiss. Similarly, if they spend 12 hours in that meeting, you're going to want to know what is going on.

These aren't reasonable numbers I've provided. More reasonable numbers are of course needed. This example merely exists to prove that a line exsists, so it can be meaningful to estimate at where it is.

However, the next question becomes what the consequences are of missing the deadline. In development, it can be a first indication of a problem codebase (hrd to maintain) or a problem developer (either not doing their work, or struggling with doing their work).

But the same metric doesn't apply to an overview/demo to new users (training) and potential customers (sales/marketing).

A training that takes longer might not be an indication of bad students (or a bad teacher). A sales pitch that takes longer isn't indicative of a problem if it actually increases the chances of selling the product.

Are estimates used as a way to justify what your developers spend their time on to non-technical management? Then you should put a reasonable limit on the estimate. Any deviation from the estimate can be justified by pointing out the unpredictable nature of the event.

This is no different from bughunting tasks. Some bugs are fixed in a matter of minutes. Others take days or weeks. You can't always know how long a problem is going to take to fix. The point of the estimate isn't to be correct, but to draw a line of reasonability, so you don't need to intervene with tasks unless someone raises a red flag or goes over the estimate and still hasn't delivered.

---

In my opinion, the bigger issue is that our team members are responsible for coordinating and in a way participating in these events.

If you mean that your developers should not be doing this job and someone else should do it, I don't quite agree.

If you mean that your developers' time spent on this should not count as development time, that is correct.

As a simplified example, let's say one of your developers is also a genius accountant, and the accounting department is in dire need of an extra pair of hands. The accounting department can't tell you how long they need him, all they say is "until the books are correct".

It makes no sense for you to put an estimate on the accounting tasks, since you're not an accountant. Secondly, an accountant's metric of success is not measured in the ability to predict outcomes but rather the precision of the actual outcome.

In these types of cases, you need to consider these demos/presentations are "development absences", i.e. the employee (not developer) is doing something for the company but is not performing development tasks.

---

But the logical consequence looms:

If I need to plan the next sprint, I need to know how long they'll be absent, and therefore I need to have an expectation of how long their absence will be.

You estimate their absence, but you don't raise a red flag if that estimate was bad. This is a matter of prioritization. If the company says that demo/presentations take precedence over development, then any justifiably absence due to demo/presentation is going to ruin sprint planning.

You can't avoid that. But the company also can't blame you for an inaccurate sprint since they themselves agreed that the demo/presentation took precedence.

This is effectively no different from a developer's absence due to sick leave, or your department not meeting the deadline because of an office fire. Reality took precedence over what you thought was going to happen. You can't avoid that. By semantical definition, you cannot expect the unexpected.

Answer 2

The meetings probably shouldn't be estimated, but the work done to prepare and conduct them should be. Designing a demo for new users is a task that doesn't exactly make the software better, but it does have a meaningful output: the demo design. Meeting prep can also have artifacts like documentation. Some of it is probably overhead, but work that needs to be done for the business is work.

I'd recommend talking it over with the team at the next retrospective, trying it out for a sprint or two and then reevaluating. If it works, it works! If not, both you and the team should better understand why it's a bad idea.

Answer 3

I don't think this is something that can be predicted, but maybe discovered.

First, get an average velocity for sprints that didn't include prepping for presentations. This is your baseline. Next find the sprints where this prep work was done and record that average velocity. Subtract the two and that gives you a rough idea what the story point value of this work entails.

Take a more granular look at each individual sprint where people did this prep work and record the difference from the normal velocity. Hopefully you can identify the exact demo that was being prepared. The difference in velocity for that sprint can be "made up" by preparing for that demo.

Some concrete numbers.

Three sprints with no prep work and your team had an average of 68 points. Three other sprints where prep work was completed came out to a 62 point average. It's starting to look like this prep work is about 6-ish points of effort for the team, so I would round that up to a standard 8 story points.

Next have a look at a specific sprint. Let's say 1 developer was preparing a demo to a new client. That sprint the team delivered 58 story points, a difference of 10 points from the normal velocity. Go ahead and round that up to 13 points.

That means if you need to demo the application to a new client in any given sprint, you have something to compare it to. Then it's just a matter of doing 1 of the following:

1. Add a 13 point story for the demo
2. Commit to delivering 13 fewer points

Pick the option that keeps project management off your back.