User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

Agile Guide podcast with Wood Zuill and Tom Cagley

Allan Kelly from Allan Kelly Associates

I’m on a mission to popularise the term Agile Guide. A few weeks ago Wood Zuill (farther of Mob Programming and force behind #NoEstimates) and I recorded a podcast with Tom Cagley – another in his SpamCast series – on the Agile Guide role.

You can download the Agile Guide podcast from libsyn or you can download it from Apple, Sitcher, Google or Spotify.

The post Agile Guide podcast with Wood Zuill and Tom Cagley appeared first on Allan Kelly Associates.

All books bundle summer discoiunt

Allan Kelly from Allan Kelly Associates

PastedGraphic-2020-08-26-18-48.png
Now seems the time to add Agile & OKRs to my all books bundle on LeanPub. This bundle allows you to buy all six of my LeanPub books in one go at a discount – $27 instead of $68. While the addition doesn’t apply retrospectively anyone buying the bundle from now on will get Agile OKRs in addition to the other six books.

And for the week the bundle is discounted to $19.99 using the code Summer33 on the LeanPub site.

(Unfortunately I can’t include The Art of Agile Product Ownership, Business Patterns or Changing Software Development in this bundle because the copyright is now owned by the publishers.)


Subscribe to my blog newsletter and download Project Myopia for Free

The post All books bundle summer discoiunt appeared first on Allan Kelly Associates.

Agile: Prix fixe or a la carte?

Allan Kelly from Allan Kelly Associates

small-andersen-jensen-Hk2eu3OODdg-unsplash-2020-08-11-14-40.jpg

Advert: September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


“They don’t do Scrum so much as ScrumBut”

“We don’t do Scrum by the book, we changed it”

“We follow SAFe, except we’ve tailored it”

“We do a mix of agile methods”

“They call it agile but it isn’t really”

You’ve heard all these comments right? But have you noticed the tone of voice? The context in which they are said?

In my experience people say these things in a guilty way, what they mean to say is:

“They don’t do Scrum so much as Scrum but we don’t do it the way we should”

“We don’t do Scrum by the book, we changed it, we dropped the Scrum Master, we flex our sprints, …”

“We follow SAFe, except we’ve tailored it by dropping the agile coaches, the technical aspects and …”

“We do a mix of agile methods, we don’t do anything properly and its half baked”

“They call it agile but I don’t think they really understand what agile is”

Practitioners aren’t helped by advisors – coaches, trainers, consultants, what-not – who go around criticising teams for not following “Brand X Method” properly. But forget about them.

I want to rid you of your guilt. Nobody should feel guilty for not doing Scrum by the book, or SAFe the right way, or perfect Kanban.

Nobody, absolutely no person or organization I have ever met or heard of, does any method by the book.

After all “agile is a journey” and you might just be at a different point on the journey right now. To me agile is learning and there is more learning to be done – should we criticise people because the haven’t learned something?

All these methods offer a price fix menu: you pay a fixed price and you get a set menu.

In reality all agile methods should be seen as an à la carte menu: pick what you like, mix and match.

In fact, don’t just pick from the Scrum menu or the SAFe menu, pick across the menus: Scrum, XP, Kanban, SAFe, LeSS, DaD, whatever!

And do not feel guilty about it.

Do it.

My agile method, Xanpan explicitly says: mix and match. Xanpan lays out a model but it also says change things, find what works for you, steal from others.

The only thing you can get wrong in agile is doing things the same as you did 3 months ago. Keep experimenting, keep truing new ways, new ideas. If you improve then great, if not, roll-back and try something else.

In other words, keep learning.

Picture: Thanks to Andersen Jensen for the above photo on Unsplash.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Agile: Prix fixe or a la carte? appeared first on Allan Kelly Associates.

Agile & OKRs – the end is in sight

Allan Kelly from Allan Kelly Associates

The end is insight for my new book “Little Book of Agile and OKRs”. There are only a few more (short) chapters I want to write and I have put the wheels in motion to get a professional cover.

After that there is a lot of editing – including a professional copy edit – and perhaps a change of title, plus an audio version.

Anyone buying “Little Book of Agile and OKRs” will receive updates for free as they are published on LeanPub.

And if you are prepared to trade a little of your time I’m give you Little Book of Agile & OKRs for free. I’m looking for reviewers, right now I’d like feedback on my content, in a few months I’ll be looking for reviews on Amazon.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Agile & OKRs – the end is in sight appeared first on Allan Kelly Associates.

Testing Testing 1 2 – video blog

Allan Kelly from Allan Kelly Associates

embed

Testing isn’t, or shouldn’t be, about finding bugs. Type-1 Testing is about ensuring you can go to Type-2 Testing and get some useful feedback. Customer feedback is the really valuable stuff: does your product address the need you saw? Is there more to do? More value to be got? – and does the value delivered justify the cost of doing it?

Testing-Testing 1 2 is a 13-minute video blog rerecording of a private presentation I did during lock-down, I hope you find it interesting.


Now booking: September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post Testing Testing 1 2 – video blog appeared first on Allan Kelly Associates.

Is Agile is obvious?

Allan Kelly from Allan Kelly Associates

iStock-1174931869-2020-07-27-14-29.jpg

From time-to-time people say to me:

“Agile is obvious”

When I’m being honest it is kind of hard to argue with them, it is certainly “obvious” to me. But at the same time agile is not obvious, or rather, the opposite of agile is also obvious. For example,

Agile says: obviously, you don’t know the future so don’t plan and research too far into the future.
Non-agile thinking says: obviously, failure to plan is planning to fail, obviously you need a plan of action, you need to plan for the future.

Agile says: obviously, people work best when they are self-motivated and given a say in what they do.
Non-agile says: obviously, people are lazy and will do as little as possible, therefore someone needs to manage them.

Agile says: high quality makes it easier to change in the future, obviously.
Non-agile says: obviously, quality is an endless quest, there is no point in polishing something which isn’t important, 20% of the effort gives 80% of the reward so don’t do any more.

Agile emphasises the here and now, the soon, obviously requirements can be handled just-in-time, so live for today.
Non-agile says: if we don’t think about the future we will obviously duplicate work and incur additional costs.

And my own entry: obviously, software development as diseconomies of scale therefore optimise for lots of small. The opposite is equally obvious: economies of scale are what makes modern business – and the cloud – successful so exploit them

There are a number of obvious examples that go with that:

Agile says: obviously we should test every change and new feature by itself to avoid the complications of interacting changes.
Non-agile says: obviously full test runs are slow and expensive so bundle work together and test it on mass.

Both agile and not-agile are obvious. What you consider obvious depends on your starting point. Once you start thinking “agile” a lot of things become obvious. But if you are not thinking agile then, if you are thinking some other model, then the opposite is also obvious.

Some would term this “An Agile Mindset”. However I don’t want to do that, I find the idea of “an agile mindset” too nebulous. I also note that most of the people I hear talking about “an agile mindset” seem to clinging on to some piece of holy lore which I consider not very agile and they believe is totally agile (the project model and upfront requirements usually.)

Instead I find myself going back to Theory-X and Theory-Y. In general people fall into one camp or the other. If you, your philosophy on work and life, align with theory-Y then all the “agile is obvious” statements above are indeed obvious. Conversely, if you generally follow a theory-X philosophy then all the non-agile statements are obvious.

Perhaps surprisingly I find people can flip, and be flipped, from X to Y. What is more difficult is getting people to unlearn behaviours and actions which they acquired with a theory-X mindset. Even if some element of theory-Y (and agile) is now obvious people need help to learn the new way and let go of the old. Some people can do this by themselves, others need help – or at least help speeding up the change.

Yes, thats part of my job as an Agile Guide. Sometimes just talking (and reflecting on recent events) helps. Sometimes exercises (or process miniatures they are sometimes called) help. Sometimes it is by experiments, exposing people to others can help as well – so conferences, user groups.

Rarely do people change because they went on training and were lectured too, but good training incorporates talking, reflection, exercises, etc. Such training is less training and more about practicing the future.

Obviously, my training is like that: I aim to make my training courses a rehearsal for future actions. Actually, while I “sell” training I prefer to think of it as a rehearsal or kaikaku event – kaikaku events also call a “kaizen blitz”, they are big change events from the people who brought you kaizen, more on them another time.

So when someone I’ve worked with turns around and says “Agile is obvious” I take it as a sign of success. They no longer seem agile as something strange, it is normal, it is onbvious.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Is Agile is obvious? appeared first on Allan Kelly Associates.

September micro-workshops

Allan Kelly from Allan Kelly Associates

I’m running all three of my half-day workshops again in September:

You can read reviews of these workshops on the Allan Kelly agile training pages where you will find more details too.
SlimCoupon-2020-07-27-14-21.jpg
Tickets are on-sale now with Tito – with a 20% early bird discount. (I’m using Tito this time because it promises to handle VAT better for those of you outside Europe.) If you have any problems with Tito or would prefer to receive an invoice contact me directly via e-mail, allan at allankelly dot net.

Blog readers can get another 15% off with the code “Blog15”.

Plus, if you book and pay for one workshop you will receive a code for 50% off the other workshops – buy one get two half price offer.

As before there are a few free tickets for the unemployed and furloughed. I might release more unemployed free tickets nearer the time so join the wait list if you are unemployed and miss out.

The post September micro-workshops appeared first on Allan Kelly Associates.