Online User Stories tutorials now complete

Allan Kelly from Allan Kelly, Software Strategy

Better User Stories
As a Product Owner I want to write better stories

I’m pleased to announce I’ve released the last of my online User Stories tutorials (part 5: Workflow and Lifecycle) and with that the whole series is complete. You can now buy the entire User Stories set of 5 tutorials as one package at a 40% discount to buying the tutorials individually.

The package includes over six hours of video commentary, exercises, quizzes, downloads and both ebook and audio book versions of Little Book of Requirements and User Stories.

Blog readers can get a further 25% off the price with the code: “blogoct21” until the end of this month, October 2021.

In addition, the first 3 people to use that code will receive a free print copy of The Art of Agile Product Ownership.

The 5 tutorials are:

These tutorials turned ouit to be a lot more work than I expected (where have i heard that before?). The core material is based on the Requirements, Backlogs and User Stories workshop that I have been running for a few years and last year converted to a series of online webinars. In the process the material has become a lot more focused.

Please, let me know what you think, in the comments section below or in the feedback forms at the end of each tutorial in the series.

The post Online User Stories tutorials now complete appeared first on Allan Kelly, Software Strategy.

7 habits of highly effective software development?

Allan Kelly from Allan Kelly

“Most of us think we don’t have enough time to exercise. What a distorted paradigm! We don’t have not to.” Stephen R. Covey

Try reading that quote again and substituting the word “refactor” for “exercise.” Or try substitute the words “test first”, or “technical excellence” for “exercise.”

It was Craig Girvan of Head Forwards at Agile on the Beach this month who pointed out to me that one of the most famous management books of all time actually contains an edict to pursue technical excellence and refactoring.

Read this snippet form The 7 Habits of Highly Effective People and as you do so think about software development, and specifically the technical quality of the code being cut:

“We are instruments of our own performance, and to be effective, we need to recognize the importance of taking time to sharpen the saw”

Whether you think of the skills of the engineers building the system, the system itself, the technology which powers the system or the process that build the code into an executable there is a resonance.

On of the things Covey emphasis in the book is that the be effective one needs not just productive capacity (“PC”, the capability to produce something) but to maintain that ability and enhance that capacity. Hence his advice to: sharpen the saw. That means using some of your PC to create more PC in future, grow the pie if you like. This is a theme he returns too many times in the book.

And that is exactly the thinking we need to put behind our software development teams: it is not just about producing something for today, it is about increasing our capability for tomorrow. Of course there is a balance, one needs to both produce today and enhance for tomorrow, find the sweat spot is hard.

In the race to deliver value today we sometimes loose that. We forget that enhancing our capability creates value because it helps us create more value tomorrow – that capability is itself valuable. In part the problem is because investing in capability enhancements has a longer payback period, the return on those investments will not be seen immediately while directing our efforts to today will deliver returns real soon.

The old “jam today or more jam tomorrow” problem. It is a balance, and getting that balance right is incredibly difficult.

But it is exactly that philosophy that lead Microsoft and Amazon to reinvest all their profits for many years. Rather than pay shareholders dividends they prefer to invest in themselves so their future capacity is greater. And because of that promise their share rise in value and shareholders benefit more than if they had paid dividends.

It’s nearly 20 years since I read 7 Habits but after Craig’s observation I fished out my copy. What struck me was how the 7 Habits themselves could be seen as a software development method in their own right:

  1. Be proactive: teams are experts in delivering useful digital products, they should be finding what is needed and working to deliver it. Simply doing what you are told is not enough. The days of sitting around waiting for a requirements document or specification are over.
  2. Begin with the end in mind: what could be more outcome focused than that? It’s not about the myriad of stories and features you will develop, its the ultimate goals that is important
  3. Put first things first: some will see this as a mandate to design the thing up front, I don’t, I see this as an instruction to start delivering value and testing hypothesis immediately. For Covey it is simply about prioritisation, “organize and execute around priorities” – simply decide what are the priorities today and get on with them.
  4. Think Win/Win: too often in development we frame decisions in confrontational terms, “Users v. developers”, “The business v. coders”, “Programmers v. testers”. One side “wins” at the others expense. We need to stop that, and we need to stop seeing the divisions. (Similar to David Cote’s argument in Winning now, Winning later.)
  5. Seek to understand first, then be understood: what a brilliant way of saying “Listen to customers” and then frame technical discussions in terms the audience will understand.
  6. Synergize: this overlaps with #4 in my mind. Covey says it is about recognising that the whole is greater than the sum of its parts. What better description of a software system could you want? All those little parts, functions, classes, modules, all working together to produce a useful whole. Yet this is one of the most difficult problems in software engineering, approaching it from either the parts or the whole creates problems. Instead we need to build something small that works, some parts that work together, and then grow it, organically.
  7. Sharpen the saw: work to have more capability tomorrow than you have today, which is where we came in

So maybe 7 Habits is a development method in disguise, or maybe its a way of thinking that should inform our approach. In fact, as I said, I read the book nearly 20 years ago, I suspect much of this has seeped into my general thinking and, without me knowing it, informed my approach.

The book may have become a cliche itself but I would still recommend reading 7 Habits.

Saw images from Luke Milburn on Wikicommons, Creative Commons License.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post 7 habits of highly effective software development? appeared first on Allan Kelly.

7 habits of highly effective software development?

Allan Kelly from Allan Kelly, Software Strategy

“Most of us think we don’t have enough time to exercise. What a distorted paradigm! We don’t have not to.” Stephen R. Covey

Try reading that quote again and substituting the word “refactor” for “exercise.” Or try substitute the words “test first”, or “technical excellence” for “exercise.”

It was Craig Girvan of Head Forwards at Agile on the Beach this month who pointed out to me that one of the most famous management books of all time actually contains an edict to pursue technical excellence and refactoring.

Read this snippet form The 7 Habits of Highly Effective People and as you do so think about software development, and specifically the technical quality of the code being cut:

“We are instruments of our own performance, and to be effective, we need to recognize the importance of taking time to sharpen the saw”

Whether you think of the skills of the engineers building the system, the system itself, the technology which powers the system or the process that build the code into an executable there is a resonance.

On of the things Covey emphasis in the book is that the be effective one needs not just productive capacity (“PC”, the capability to produce something) but to maintain that ability and enhance that capacity. Hence his advice to: sharpen the saw. That means using some of your PC to create more PC in future, grow the pie if you like. This is a theme he returns too many times in the book.

And that is exactly the thinking we need to put behind our software development teams: it is not just about producing something for today, it is about increasing our capability for tomorrow. Of course there is a balance, one needs to both produce today and enhance for tomorrow, find the sweat spot is hard.

In the race to deliver value today we sometimes loose that. We forget that enhancing our capability creates value because it helps us create more value tomorrow – that capability is itself valuable. In part the problem is because investing in capability enhancements has a longer payback period, the return on those investments will not be seen immediately while directing our efforts to today will deliver returns real soon.

The old “jam today or more jam tomorrow” problem. It is a balance, and getting that balance right is incredibly difficult.

But it is exactly that philosophy that lead Microsoft and Amazon to reinvest all their profits for many years. Rather than pay shareholders dividends they prefer to invest in themselves so their future capacity is greater. And because of that promise their share rise in value and shareholders benefit more than if they had paid dividends.

It’s nearly 20 years since I read 7 Habits but after Craig’s observation I fished out my copy. What struck me was how the 7 Habits themselves could be seen as a software development method in their own right:

  1. Be proactive: teams are experts in delivering useful digital products, they should be finding what is needed and working to deliver it. Simply doing what you are told is not enough. The days of sitting around waiting for a requirements document or specification are over.
  2. Begin with the end in mind: what could be more outcome focused than that? It’s not about the myriad of stories and features you will develop, its the ultimate goals that is important
  3. Put first things first: some will see this as a mandate to design the thing up front, I don’t, I see this as an instruction to start delivering value and testing hypothesis immediately. For Covey it is simply about prioritisation, “organize and execute around priorities” – simply decide what are the priorities today and get on with them.
  4. Think Win/Win: too often in development we frame decisions in confrontational terms, “Users v. developers”, “The business v. coders”, “Programmers v. testers”. One side “wins” at the others expense. We need to stop that, and we need to stop seeing the divisions. (Similar to David Cote’s argument in Winning now, Winning later.)
  5. Seek to understand first, then be understood: what a brilliant way of saying “Listen to customers” and then frame technical discussions in terms the audience will understand.
  6. Synergize: this overlaps with #4 in my mind. Covey says it is about recognising that the whole is greater than the sum of its parts. What better description of a software system could you want? All those little parts, functions, classes, modules, all working together to produce a useful whole. Yet this is one of the most difficult problems in software engineering, approaching it from either the parts or the whole creates problems. Instead we need to build something small that works, some parts that work together, and then grow it, organically.
  7. Sharpen the saw: work to have more capability tomorrow than you have today, which is where we came in

So maybe 7 Habits is a development method in disguise, or maybe its a way of thinking that should inform our approach. In fact, as I said, I read the book nearly 20 years ago, I suspect much of this has seeped into my general thinking and, without me knowing it, informed my approach.

The book may have become a cliche itself but I would still recommend reading 7 Habits.

Saw images from Luke Milburn on Wikicommons, Creative Commons License.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post 7 habits of highly effective software development? appeared first on Allan Kelly, Software Strategy.

Questioning the great work from home experiment

AllanAdmin from Allan Kelly

18 months ago everyone who worked in an office was sent home, and told “work from home.” Suddenly even the most anti-work from home companies and bosses had to accept it. Even the slowest, bureaucratic, IT departments had to support remote working.

In many ways it has been a great experiment – an experiment that is judged a success because people have been more productive than expected. And look… the western economies are still here. Indeed, some businesses have boomed.

But, I don’t think that was the great experiment. To my mind the great experiment starts now – now that people are getting the option to work in the office or work from home, now that big-bad-managers can lean on people to go into the office and start using “presenteeism” again.

There are a few of points about the great work from home which I think are generally missed. It is because these points no longer apply which makes me thing now is the true experiment. I’ve also got a bunch of concerns, I’m not convinced that surviving the last 18 months by working-from-home is the way we should carry on.

First, the great work-from-home was egalitarian: it wasn’t a privilege or a punishment. Nor was it self-selecting: whether you wanted to or not you did it.

Second, everyone had to do it so everything was online. There were no meetings with some people in one room and others hanging on the end of a telephone, the kitchen was no longer a place for side chats and the smokers couldn’t have their own meetings outside the back door.

Third there was no end date: there was no option to say “we’ll decide it when we are all in the office.”

Finally, last but not least: at least initially it was existing people and teams so relationships and social-capital already existed People were used to working together already.

Bringing in new people, “onboarding” and “enculturing” is always hard, its a lot harder online – and being honest, one of the things I find hardest is finding my way into a new team when everything is online.

As work-from-home has gone on teams have had to learn to recruit and incorporate new people online.

Now, as people drift back to the office – at different paces in different places – these points don’t hold. Now being in the office or not is often a choice, it is no longer whole teams so those side conversations are back.

To my mind this is an even bigger experiment than the great work-from-home; and I think it is going to prove more difficult for companies and teams to navigate.

Personally, I’m really lucky, I’ve had my office in my home for years so I’m all set up for it. But I’m sick of working in the same place day-after-day for months on end. While I’m sure many people never want to see an office again I think there will be many others who are keen to go back to the office.

Next, I have a few fears about the extended remote working model. First off is mental health: without an office, without the journey to and from the office, without the change of clothes that all involves there is less separation between work and home. Without dividing lines that means work impinges on home time and it is difficult to escape work stress.

Second, online working is far more dependent on the written form. That means that those of us who struggle with the written form are at a disadvantage.

Yes I know I’m a bad example, I write too much. But look at all my grammatical and spelling foibles – I’m dyslexic. I’ve learned to be good at writing but really I’d rather be talking.

As e-mail replaces the telephone, Slack replaces the talking across the desk, WhatsApp replaces coffee conversations those of us who struggle with writing are disadvantaged.

Next, I’m concerned for younger people, those who only entered the work force recently. How are they to learn about their job? How are they to learn work culture, let along specific company culture if there is no office?

And most those same people are often in a more difficult position. They are stilling with their parents in their childhood bedroom, or they are living in a house share with problematic internet. In short, younger people need the office more and they need older people as role models and teachers.

Finally, I feel a lot of technology people – programmers specifically – are very keen to push back on any suggestion that face-to-face communication, and co-location, has any advantages. It seems very acceptable to say “We can do everything online, there is no difference.”

I beg to differ. If only because without body language, without facial expressions, without seeing how people react then communication is less – the old “80% of communication is non-verbal” idea. You can do a lot online, but you can also do a lot in person.

Unfortunately I don’t see this debate. I don’t see people discussing “what is best done online” and “what is best done in person.” I see my fellow digital workers being very quick to push back on anyone that questions online working.

Perhaps it’s me, but I feel the technology community is so anti-office work that I have hesitated even to voice these concerns. Anyone else share these views? Or am I persona non-grata?


Subscribe to my blog and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Questioning the great work from home experiment appeared first on Allan Kelly.

Questioning the great work from home experiment

AllanAdmin from Allan Kelly Associates

18 months ago everyone who worked in an office was sent home, and told “work from home.” Suddenly even the most anti-work from home companies and bosses had to accept it. Even the slowest, bureaucratic, IT departments had to support remote working.

In many ways it has been a great experiment – an experiment that is judged a success because people have been more productive than expected. And look… the western economies are still here. Indeed, some businesses have boomed.

But, I don’t think that was the great experiment. To my mind the great experiment starts now – now that people are getting the option to work in the office or work from home, now that big-bad-managers can lean on people to go into the office and start using “presenteeism” again.

There are a few of points about the great work from home which I think are generally missed. It is because these points no longer apply which makes me thing now is the true experiment. I’ve also got a bunch of concerns, I’m not convinced that surviving the last 18 months by working-from-home is the way we should carry on.

First, the great work-from-home was egalitarian: it wasn’t a privilege or a punishment. Nor was it self-selecting: whether you wanted to or not you did it.

Second, everyone had to do it so everything was online. There were no meetings with some people in one room and others hanging on the end of a telephone, the kitchen was no longer a place for side chats and the smokers couldn’t have their own meetings outside the back door.

Third there was no end date: there was no option to say “we’ll decide it when we are all in the office.”

Finally, last but not least: at least initially it was existing people and teams so relationships and social-capital already existed People were used to working together already.

Bringing in new people, “onboarding” and “enculturing” is always hard, its a lot harder online – and being honest, one of the things I find hardest is finding my way into a new team when everything is online.

As work-from-home has gone on teams have had to learn to recruit and incorporate new people online.

Now, as people drift back to the office – at different paces in different places – these points don’t hold. Now being in the office or not is often a choice, it is no longer whole teams so those side conversations are back.

To my mind this is an even bigger experiment than the great work-from-home; and I think it is going to prove more difficult for companies and teams to navigate.

Personally, I’m really lucky, I’ve had my office in my home for years so I’m all set up for it. But I’m sick of working in the same place day-after-day for months on end. While I’m sure many people never want to see an office again I think there will be many others who are keen to go back to the office.

Next, I have a few fears about the extended remote working model. First off is mental health: without an office, without the journey to and from the office, without the change of clothes that all involves there is less separation between work and home. Without dividing lines that means work impinges on home time and it is difficult to escape work stress.

Second, online working is far more dependent on the written form. That means that those of us who struggle with the written form are at a disadvantage.

Yes I know I’m a bad example, I write too much. But look at all my grammatical and spelling foibles – I’m dyslexic. I’ve learned to be good at writing but really I’d rather be talking.

As e-mail replaces the telephone, Slack replaces the talking across the desk, WhatsApp replaces coffee conversations those of us who struggle with writing are disadvantaged.

Next, I’m concerned for younger people, those who only entered the work force recently. How are they to learn about their job? How are they to learn work culture, let along specific company culture if there is no office?

And most those same people are often in a more difficult position. They are stilling with their parents in their childhood bedroom, or they are living in a house share with problematic internet. In short, younger people need the office more and they need older people as role models and teachers.

Finally, I feel a lot of technology people – programmers specifically – are very keen to push back on any suggestion that face-to-face communication, and co-location, has any advantages. It seems very acceptable to say “We can do everything online, there is no difference.”

I beg to differ. If only because without body language, without facial expressions, without seeing how people react then communication is less – the old “80% of communication is non-verbal” idea. You can do a lot online, but you can also do a lot in person.

Unfortunately I don’t see this debate. I don’t see people discussing “what is best done online” and “what is best done in person.” I see my fellow digital workers being very quick to push back on anyone that questions online working.

Perhaps it’s me, but I feel the technology community is so anti-office work that I have hesitated even to voice these concerns. Anyone else share these views? Or am I persona non-grata?


Subscribe to my blog and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Questioning the great work from home experiment appeared first on Allan Kelly Associates.

Splitting & slicing user stories

Allan Kelly from Allan Kelly

I’m please to announce the fourth part of my User Stories tutorial is now available.

User Stories by example, part 4: Splitting stories

In this tutorial I look at 10 days to split a story and illustrate each with examples and exercises.

I have one more part of this tutorial series to deliver, Workflow and Lifecycle, hopefully I’ll have that out in the next month.

Until then please try the tutorial and let me know what you think.

The post Splitting & slicing user stories appeared first on Allan Kelly.

Splitting & slicing user stories

Allan Kelly from Allan Kelly Associates

I’m please to announce the fourth part of my User Stories tutorial is now available.

User Stories by example, part 4: Splitting stories

In this tutorial I look at 10 days to split a story and illustrate each with examples and exercises.

I have one more part of this tutorial series to deliver, Workflow and Lifecycle, hopefully I’ll have that out in the next month.

Until then please try the tutorial and let me know what you think.

The post Splitting & slicing user stories appeared first on Allan Kelly Associates.

The Sprint Goal?

Allan Kelly from Allan Kelly

Hi Allan, what do you think of this as a Spring Goal?
  • Prototype store locator
  • Deploy product selector to live
  • Fix accessibility defects identified by client
  • Complete visual design of search feature
  • Security fixes & updates
  • Team improvement: refactor VX tables, page template processor”

I answer:

“This looks more like a sprint backlog than a sprint goal.”

This e-mail exchange sums up the problem with the sprint goal, or rather, the sprint goal as it so often ends up being used.

The sprint goal has always been part of Scrum even if it has often been forgotten. The idea behind it was to say: “What is the outcome this team needs to make happen this sprint?” The goal was meant to be a non-trivial thing, a meaningful step forward, an outcome, perhaps a challenge, certainly a rallying point.

However the sprint goal fell into disuse. When I used to run teams I never used it – partly because my teams have never used strict Scrum but also because most of the teams I worked with had multiple things happening. The teams were expected to make progress across a broad front. Conversely the sprint goal focuses the team on a single thing.

My experience was far from unique. And, if I’m being honest, in the days when I gave agile training regularly I never talked about it much. Again, most of the teams I encountered were expected to “deliver stuff” it was more a case of “burning down the backlog.”

When I did see the sprint goal used it was normally used in reverse. Rather than teams setting a goal and asking “What do we need to do to make this happen?” teams would decide on a collection of stories from the backlog and then ask “What is the goal we can write that describes this collection of items?” In such cases the goal might as well be “Do stuff” or perhaps “Do the collection of stories we think we can do.”

The goal was meaningless so why bother?

Yet I detect a change in the air. In the last few years I’ve heard the sprint goal talked about more and I’ve observed teams setting a goal more often. Plus, as I wrote in Succeeding with OKRs in Agile, a sprint goal sits well with OKRs – it also provides a way to cut through the tyranny of the backlog.

Unfortunately I have to report the teams I see setting sprint goals are still setting goals about “Do these stories from the backlog.”

Why is this?

Perhaps it is because the sprint goal is misunderstood or perhaps it is because people are aiming to tick off as many Scrum practices as they can, maybe they feel they must use the goal because Scrum lists it.

I’m sure both of these reasons are at play but I think the main reason is because of backlog fetish and the expectation that teams “do the backlog.” Teams – and especially product owners – don’t have the skills or aren’t being given the authority to make decisions about what to do based on fresh information arriving from customers, analytics and analysis.

That is: most teams are still expected to burn-down the backlog.

Well, it is one way of working, I understand the logic, and burning-down a backlog with Scrum is probably still better than ticking off use cases from a requirements document in a waterfall; but it still leaves so much opportunity unrealised. Things could be so much better if teams really worked to sprint goals and OKRs rather than labouring under the tyranny of the backlog.

So if you want some practical advice: if you are setting sprint goals in reverse just give up, accept that you “do backlog items” and save yourself the time of inventing a goal.

And if you are not setting a sprint goal: have a serious talk about it as a team, examine what having a sprint goal would mean and how you might work differently. Then experiment with using a sprint goal for a few sprints.

This advice goes doubly if you are a Product Owner, seriously using sprint goals is going to relieve you of a lot of backlog administration but means you will need to think hard about goals and what will really improve your product.


Subscribe to my blog newsletter and download Continuous Digital for free

(normal price $9.99/£9.95/€9.95)

The post The Sprint Goal? appeared first on Allan Kelly.

The Sprint Goal?

Allan Kelly from Allan Kelly Associates

Hi Allan, what do you think of this as a Spring Goal?
  • Prototype store locator
  • Deploy product selector to live
  • Fix accessibility defects identified by client
  • Complete visual design of search feature
  • Security fixes & updates
  • Team improvement: refactor VX tables, page template processor”

I answer:

“This looks more like a sprint backlog than a sprint goal.”

This e-mail exchange sums up the problem with the sprint goal, or rather, the sprint goal as it so often ends up being used.

The sprint goal has always been part of Scrum even if it has often been forgotten. The idea behind it was to say: “What is the outcome this team needs to make happen this sprint?” The goal was meant to be a non-trivial thing, a meaningful step forward, an outcome, perhaps a challenge, certainly a rallying point.

However the sprint goal fell into disuse. When I used to run teams I never used it – partly because my teams have never used strict Scrum but also because most of the teams I worked with had multiple things happening. The teams were expected to make progress across a broad front. Conversely the sprint goal focuses the team on a single thing.

My experience was far from unique. And, if I’m being honest, in the days when I gave agile training regularly I never talked about it much. Again, most of the teams I encountered were expected to “deliver stuff” it was more a case of “burning down the backlog.”

When I did see the sprint goal used it was normally used in reverse. Rather than teams setting a goal and asking “What do we need to do to make this happen?” teams would decide on a collection of stories from the backlog and then ask “What is the goal we can write that describes this collection of items?” In such cases the goal might as well be “Do stuff” or perhaps “Do the collection of stories we think we can do.”

The goal was meaningless so why bother?

Yet I detect a change in the air. In the last few years I’ve heard the sprint goal talked about more and I’ve observed teams setting a goal more often. Plus, as I wrote in Succeeding with OKRs in Agile, a sprint goal sits well with OKRs – it also provides a way to cut through the tyranny of the backlog.

Unfortunately I have to report the teams I see setting sprint goals are still setting goals about “Do these stories from the backlog.”

Why is this?

Perhaps it is because the sprint goal is misunderstood or perhaps it is because people are aiming to tick off as many Scrum practices as they can, maybe they feel they must use the goal because Scrum lists it.

I’m sure both of these reasons are at play but I think the main reason is because of backlog fetish and the expectation that teams “do the backlog.” Teams – and especially product owners – don’t have the skills or aren’t being given the authority to make decisions about what to do based on fresh information arriving from customers, analytics and analysis.

That is: most teams are still expected to burn-down the backlog.

Well, it is one way of working, I understand the logic, and burning-down a backlog with Scrum is probably still better than ticking off use cases from a requirements document in a waterfall; but it still leaves so much opportunity unrealised. Things could be so much better if teams really worked to sprint goals and OKRs rather than labouring under the tyranny of the backlog.

So if you want some practical advice: if you are setting sprint goals in reverse just give up, accept that you “do backlog items” and save yourself the time of inventing a goal.

And if you are not setting a sprint goal: have a serious talk about it as a team, examine what having a sprint goal would mean and how you might work differently. Then experiment with using a sprint goal for a few sprints.

This advice goes doubly if you are a Product Owner, seriously using sprint goals is going to relieve you of a lot of backlog administration but means you will need to think hard about goals and what will really improve your product.


Subscribe to my blog newsletter and download Continuous Digital for free

(normal price $9.99/£9.95/€9.95)

The post The Sprint Goal? appeared first on Allan Kelly Associates.

Unplanned work after the sprint starts?

Allan Kelly from Allan Kelly Associates

“Should unplanned work be allowed after the sprint starts?”

One of those questions which comes up again and again. And it came up last week when I visited a clients offices – yes I actually visited a client! The answer to this question is, as often happens: It depends. So let me give you my thinking.

First, many teams have a rule that work must be scheduled in the sprint planning meeting, after which this is fixed. Teams have a right to make this rule so if this is a team rule – what Kanban folk call a policy – then work is not allowed in.

This rule is based on a strict interpretation of Scrum. The thinking – particularly in early implemenations of Scrum – was that changing priorities was a big problem for teams and therefore fixing the work to be done for a few weeks made sense. In the event of that things did change the team would declare an “abnormal termination of sprint” and move to start a new sprint with new priorities.

Now for some teams this makes complete sense. Barring work from entering the sprint after planning makes complete sense. Equally it makes sense for team members to only do work scheduled in the sprint and refuse all other work. So, it depends… when a team is troubled by new work appearing, priorities changing, and when a team are expected to deliver something new – when their overarching priority is not support but building something new – then this approach makes complete sense.

But, don’t follow this rule just because you think Scrum says so. I just had a quick look at the latest Scrum Guide doesn’t actually mention abnormal termination of sprint. It does say “No changes are made that would endanger the Sprint Goal” which then leads us into a conversation about the sprint goal but let’s hold that for now.

Now ring fencing the team and the sprint like this solves one set of problems but it creates another set. If the team are aiming to be reactive why would they not pick up work?

And as teams increasingly become DevOps or SecDevOps, or BizDev, or whatever, things get more complicated. It would be irresponsible to hold a “no work enters the sprint” if the live server was down or a security hole had been found. But at the same time, being hyper-reactive has a downside because the team would be constant distracted.

Ultimately it is the Product Owner who should have the final say on whether work is unplanned work is accepted or not but when you have a customer on the phone someone else may be forced into a decision.

I apply two tests: is the unplanned work really urgent? – or could it wait a few days and be considered in the next sprint. (Or even queued in the backlog for longer.)

Second, is the unplanned work valuable? – namely, is it more valuable than the work the team are doing and would be displaced by this work. Ideally it would valuable enough to justify the disruption it causes by late entry too.

Hence I like to talk about urgent but valuable unplanned work. Just because something appears after sprint planning doesn’t mean it is not valuable. If the work is urgent, and if it is valuable enough, then it deserves to enter the sprint and get done.

However I like to build in two feedback loops. First, as the work arises, does the person raising the work understand the disruption this will cause? Are they prepared to accept that some other work may not get done?

I like to make this real: pull up your board and show the requester the consequences. Let them prioritise the work against the current planned work. This can make the unplanned work go away.

Second, mark the late-breaking work so you can track it through the system – on a physical board I would use a yellow card. At the end of the sprint review how many yellow cards you have and talk about whether the right decision was made.

Over time, as you build up your data – and stock of done yellow cards – you can reason about the cards and decide your long term action. For example,

You might want to make an allowance in sprint planning for unplanned work: suppose your team averages 3 yellow cards a sprint, then, when you are planning the sprint allow space for them.

If you have many yellow cards regularly you might even want to move to a Kanban model or split the team.

Review the requests, what are the common themes? – is there a module which is particularly troublesome, would some remedial work help reduce the unplanned work.

Or is there someone in particular who raises unplanned work? Should the team leaders talk to this person and see if they could change their behaviour, perhaps they could make their requests a few days earlier.

Maybe you want to ring-fence a team member to deal with unplanned work while the rest of the team pushes on with the main work.

As I said at the top of this post, the unplanned work question comes up a lot. I discussed it in Xanpan so if you want more examples go there. And if you have any other suggestions please comment on this post.


Subscribe to my blog newsletter and download Continuous Digital for free

The post Unplanned work after the sprint starts? appeared first on Allan Kelly Associates.