How to add iterative tasks to a sprint

For example, say the team has four ideas that each need to be set up, applied and then tested and the PO wants a solution by the end of the next sprint.

@Barry McCullagh, Are the four ideas together contributing to a common hypothesis that needs to be validated i.e. Sprint Goal? Can the outcomes of the 4 ideas be done individually or do they all need to be done at once?

If the Sprint Goal is to provide a solution, it seems like the team would need to prioritize the experiments based on which ones are the most likely to be viable and run as many as possible in parallel, perhaps making tradeoffs between viability and which ones can be run concurrently. Perhaps there's background that I don't have, but this seems to be much like concurrent engineering.

I would suggest that the Definition of Done would not be a successful experiment, but rather the completion of the experiment and any required analysis and reporting. In the event that you are tracking velocity, "credit" would be granted not by the success of the experiment but by completing the work and being able to learn from it.

I would say, though, that the Sprint Goal of providing a solution may be a little demotivating, especially if none of the experiments turn into something viable. That may be something that you want to look at.

Assuming that the team can agree and commit to a Sprint Goal, why not plan any emergent tasks on a just-in-time basis?

Hi all,

Thanks for the replies.

@Steve Matthew and @ Thomas Owens, the experiment cycles would need to be completed independently, both from a resources perspective and from a verification point of view (can we use anything from this experiment to potentially improve the output of the next one).

In terms of de-motivation if no solution is achieved in the sprint, in reality it isn't that black and white, I was just trying to get the general idea across. Progression towards a solution would be more like the goal.

@Ian Mitchell, Would planning emergent tasks require sitting down with the PO and have their approval or is it reasonable for the SM to create new tasks and add them straight to the sprint?

Best wishes,

Barry

Would planning emergent tasks require sitting down with the PO and have their approval or is it reasonable for the SM to create new tasks and add them straight to the sprint?

The Development Team own their Sprint Backlog. It’s their forecast of work for meeting the Sprint Goal.

It sounds like you have an outcome-focused Sprint Goal. I think that's brilliant, and something that most teams should try a lot more often!

If you can provide an example Sprint Goal, it would probably help this discussion, but in the mean time, I'll pick one to illustrate my point: Produce a chocolate bar that is healthier and tastes better than its leading competitor.

Experiment one might be to produce a prototype of a low-fat alternative to Mars, and run a series of taste tests on consumers. If that is successful, or at least shows potential, all remaining effort in the sprint might be spent improving the recipe to get a better tasting or healthier bar.

Should experiment one show that this concept is flawed, a completely different recipe might be tried, or an attempt made to compete with a different chocolate bar.

If all of the experiments fail, there should at least be evidence to help decide whether it's prudent to invest further sprints in this venture.

In order to focus, the Development Team might initially only pull experiments into the Sprint Backlog which relate to competing with the Mars bar; but there could be other ideas on the Product Backlog, relating to other chocolate bars, which would only come into play once the first idea has proved successful, or been ruled out.

The forecast might not necessarily be identical to the initial state of the Sprint Backlog. For example, it could be a combination of known backlog items, and an amount of as yet unknown work:

• Hypothesis: the first Mars-competitor prototype tastes better to 18–24 year olds
• Hypothesis: the first Mars-competitor prototype tastes better to 40–60 year olds
• Hypothesis: the first Mars-competitor prototype causes lower blood-sugar spikes in Type-2 diabetics
• 15 additional experiments
• 3 further fully-tested prototypes

This might be more transparent than pretending anything else is known at the start of the Sprint.

@Simon - that is an excellent example, quite relevant and as good as anything I could put out on a public forum. Thanks. On the outcome-focused goals, we still have this in a 2-week time box. Would you normally consider an outcome-focused goal to be less time restrained?

@Ian (and others!) - I understand that the development team own the sprint backlog, however, using Simon's example, how and when can new tasks be created and added in an unpredictable development scenario?

Building on Simon's example our processes would have three aspects to the development: The outer chocolate, the caramel and the nougat. Each batch of nougat takes 2 working days to design, make and test while each batch of caramel takes 10 days to design test and make with the chocolate having a 6 day cycle.

We anticipate that the biggest problem will be getting the density of the nougat correct and we can perform many iterations of nougat design within the same time frame as one caramel design and one chocolate design. Before the sprint starts we have one set of tasks (design recipe, make, test) related to initial batch of chocolate, caramel and nougat. We also want to create additional sets of tasks related to making the nougat less dense and to make it more dense.

We don't know how many of each we will need in the current sprint and reducing the length of the sprint to one nougat cycle means that a single caramel batch will spread across several sprints or we will need to divide the development team across different sprints.

Should we populate the product backlog with nougat related tasks which the SM can bring into the sprint backlog when needed, or run mini-sprints just for the nougat development group?

Thanks again and best wishes,

Barry

We don't know how many of each we will need in the current sprint and reducing the length of the sprint to one nougat cycle means that a single caramel batch will spread across several sprints or we will need to divide the development team across different sprints.

In Scrum, each Sprint must yield an increment of value no matter how small it may be. That increment has to be releasable so empiricism is facilitated. It's therefore possible to spread large pieces of work across multiple Sprints, as long as something is planned and delivered which enables validated learning. This principle is often applied to infrastructure and set-up work, but it would hold for a batch of caramel. The caramel might take several Sprints, but you could inspect and adapt for nougat.

This isn't ideal, because although empirical process control is demonstrably present, it is nevertheless attenuated. Most of the work being done is for something else, and it won't be validated until several Sprints have elapsed. There are at least two broad options:

• You could revise a Sprint cadence to a maximum of one month, and thereby plan multiple experiments with caramel, chocolate, and nougat. Most of these could be emergent, being planned just-in-time in pursuit of the Sprint Goal of a healthier and tastier bar. A good Sprint length ought to be chosen, at least in part, because of considerations like this.
• You could align the chocolate and nougat experiments in such a way that they also shape and validate the long-term work being performed on nougat. This principle is often applied with set-up work, where a small user story (tracer bullet) is chosen not just to deliver nominal value, but to validate the substantial infrastructure work being undertaken (e.g. a transaction encompassing all architectural layers might be demonstrated).

Would you normally consider an outcome-focused goal to be less time restrained?

That might prove necessary, but I would at least try to be outcome-focused without increasing the timebox. A sprint can be as long as a calendar month, but it is of course also possible to keep measuring outcomes, long after an Increment was produced and released.

Should we populate the product backlog with nougat related tasks which the SM can bring into the sprint backlog when needed, or run mini-sprints just for the nougat development group?

Well, it should be up to the Development Team to manage the Sprint Backlog, not the Scrum Master.

But responding to your wider point… planning work that might ultimately be discarded is waste, but it's important to differentiate between necessary waste, and unnecessary waste. Do either of these procedures help to maximize the value delivered?

@Ian Mitchell and @Simon Mayer have done a fantastic job of explaining this. I learned a lot by reading it.  Thanks to all 3 of you for putting this here.  I am going to touch on one thing and one thng only because I felt like it got lost in the narrative. 

Would planning emergent tasks require sitting down with the PO and have their approval or is it reasonable for the SM to create new tasks and add them straight to the sprint?

Scrum Master does not create tasks for the Development Team in the Sprint Backlog.  The Development Team owns that body of work and they are responsible for making the plan to satisfy the work visible and understandable. So the Development Team would create any and all tasks necessary because they are the ones doing the actual work.

BTW, if your team does come up with an alternative to the Mars bar, please let me know. I love Mars bars and would very much like to try a better alternative. 

@Daniel, yes @Ian Mitchell and @Simon Mayer have done a great job of explaining and persevering up with my questions!

Okay, I get it, I get it! The dev team owns the sprint backlog ;)

It was my incorrect understanding that the PO should be involved in task creation, but, as @Daniel Wilhite said a few months ago (https://www.scrum.org/forum/scrum-forum/31903/who-creates-tasks-user-st…) that is not the case.

To try to draw this to a conclusion, at least until we go through a few more sprints and I have more experience, I think the creation of tasks during the sprint (I believe that this is what Ian means by emergent tasks) is less wasteful than other approaches and if my knowledge of scrum had been better we could have nipped this in the bud a few days back.

Reducing the sprint to the length of nougat means a lot more sprint review, retrospective and planning meetings which is potentially wasteful of time, because, literally, our 'nougat' item cycle is two or three days. Planning unnecessary tasks is also wasteful. 

Unless what I have suggested goes against a part of scrum I am unaware of, this is what I will do for the next while.

Thanks again to @Ian Mitchell, @Simon Mayer, @Daniel Wilhite, @Thomas Owens, @Steve Matthew for your help.

Barry