A New Definition of ‘Epic’ 2

June 4th, 2010

This is the second post on a new definition of ‘epic’. The first post is all about types of story. If you haven’t read that first post, it might be a good idea to read that first. This post looks at the other elements (not stories per se) that crop up as inputs to requirements.

On day one, before running any workshops or conducting any interviews, you have to become familiar with the documents that have already been written. There might be reports, or project mandates, or business cases to read, or whatever. A good approach is to read the documents and start creating index cards for each salient point you encounter. Then it’s a question of making sense of them, categorising them, and creating a requirements hierarchy. Let me be absolutely clear on the point that I am not advocating a big requirements effort upfront reminiscent of ‘waterfall’. I’m just taking the pragmatic approach that whatever you do going forward, there is a need to make sense of what’s already gone on. This can be termed ‘traceability’. How can you demonstrate that what you propose in a couple of weeks time (a nicely groomed backlog – filled with implementable testable functional stories) satisfies all the inputs that have already been given?

Non-story inputs include:

  • Constraints: a condition that must not be broken
  • Non-functional requirement: a condition that must be exhibited
  • Business rules: related to a particular story (functional behaviour). Implemented as an if…then… condition. Often related to ‘state’ of a business object
  • Implementation tales: someone’s suggestion as to how the solution will be implemented
  • Acceptance criteria: related to a particular story (functional behaviour). A test that can be run to determine whether a story concludes in the manner desired

Even if you are starting the project from the outset, not everything people tell you is going to make a good candidate story. Take ‘security’. Say somebody tells you the system needs to be ‘secure’. This seems like a statement of the obvious; of course the system needs to be secure. Are you going to write a story:

As a data specialist

I need to ensure our customer data is secure from outside hacking and mis-use

So that data is not stolen and customers compromised bringing bad publicity on to the organisation

Clearly it is possible to describe ‘security’ as a story (as demonstrated above) but is it the best way of articulating the need? Is it the best use of your time? There are no hard and fast rules about categorisation, but there are guidelines (although there remains ambiguity and we can argue about it). Again though, remember we are ultimately aiming to get that well-groomed backlog created, and that means defining stories the programmers can implement as functional behaviour. Nobody is going to use your new system and come to it with the express objective of ensuring their data is secure. They are just going to use it with the expectation their data is secure. The system needs to function without breaking the rule that data is secure, so it’s natural to see ‘security’ as a constraint; behaviour that is not violated while the system is in use.

Figure: A new definition of a ‘project epic’.

Tags: , , , , , , , ,
Posted in Big picture | No Comments »

A New Definition of ‘Epic’?

June 2nd, 2010

There are five different types of ‘story’ the master story teller will deal with. The first two are Enterprise stories and Back stories which are related. These types of ‘story’ are discovered by the story teller when the project is already ‘in-flight’ and the job is to demonstrate traceability. Typically the first two types of story are not told in the classic format of (As a… I need to… So that…). They may be in any format, and it is of limited value to convert them into the standard format. The story teller should consider these types of story as a source of ‘reference’.

Enterprise story: (1) a management aspiration that is not project specific e.g. ‘Recapture the number one position in the market within 12 months by customer satisfaction and sales revenue’. ‘To reduce maintenance costs by 15% over the financial year’. ‘To increase expenditure on frontline services by 12%.’ ‘To reduce customer ‘churn’ by increasing customer satisfaction. (2) A ‘command’ from senior management that is project specific. ‘The new content management system (CMS) will use templates’, ‘The CMS will delegate content management to content owners i.e. without the need for technical resource’.

It is unnecessary to write enterprise stories in the classic user story format (As a… I need to… So that…). Enterprise stories are not directly implementable in code.

Back story: a back story is an input to the requirements gathering process that has been uncovered by the analyst during investigation of pre-existing requirements artefacts. Back stories are similar to the second definition of Enterprise stories, however they do not originate from senior management i.e. ‘The new content management system (CMS) will use templates’ could equally be a back story if it is discovered in a document written by non-senior management. The reason for separating out back stories from this type of enterprise story is to demonstrate traceability to different audiences in the organisation.

There are three types of ‘classic’ user story, all of which are hierarchically related.

  • Project story
  • Release story
  • Iteration story

Project story: states the goals of the project from the perspective of the individual users who will use the system under consideration. Project stories are the basis of user acceptance testing. Project stories describe the end-to-end navigation of a particular business process. Project stories satisfy enterprise stories. Project stories are not directly implemented in code as they are satisfied by the aggregation of release/iteration stories.

—

As a customer

I want to explore opportunities

So that I can take advantage of new pricing plans

—

As a customer

I need to get answers to my questions

So that I can get the most out of my service

—

As a content owner

I need to provide answers to customer questions

So that customers can get answers to their questions

—

Release story: a functional decomposition of a project story that represents value to the customer/users in a standalone fashion. Collectively release stories satisfy project stories.

—

As a content owner

I need to create new content

So that information informs customers about new pricing plans or answers to questions, or general information of value to customers

—

As a content owner

I need to maintain existing content

So that information is relevant and current to inform customers about new pricing plans or answers to questions or general information of value to customers

—

As a content owner

I need to find relevant and related content

So that I can maintain the information and avoid creating duplicate or misleading messages

—

Iteration story: a functional decomposition of a release story that is of a size that it can be delivered in a single iteration. Collectively iteration stories satisfy release stories.

As a content owner

I need to find all content that relates to pricing plans for a given mobile device

So that a summary can be returned and the relevant information displayed.

—

As a content owner

I need to be able to modify the text on the page relating to prices

So that pricing data can be modified

—

And when you put this work together you get a graphic representation that looks like this:

The story teller will encounter other kinds of inputs to the ‘big picture’. It is tempting to consider all stories, all types, and all other inputs, when you put them all together, as being the ‘epic’. Unfortunately, the word ‘epic’ is already used in the Agile world to mean ‘a story that is too big’. This is unfortunate because there is a shortage of suitable words, and epic is such a good one it’s a shame it is used for such a non-specific concept. Instead, you can use the term ‘big picture’. The epic/big picture includes the story types we’ve just looked at plus the following:

  • Constraints
  • Acceptance criteria (related to stories)
  • Business rules
  • Implementation tales
  • Non-functional requirements

The story teller has to know how all these inputs fit together. This is the subject of a later posting though. I’ll also be publishing graphics and spreadsheets that show how these elements all fit together so you can tell the epic, show the big picture to other people in the team in readiness for the first and subsequent iterations. Stay tuned.

Tags: , , , , , , , ,
Posted in Storytime | 1 Comment »

The Baby and the Bathwater

June 1st, 2010

Every now and then people get so fed up with software failure they reckon it must be a systemic problem and they throw the collective knowledge in the bin and start again. This is the hunt for the silver bullet. The magic weapon to slay the vampire. This happened with use cases when user stories came along. It’s a shame. It’s lucky that use cases got stuck in the U-bend, and somebody used the plunger to suck them back up again.

The problem is not, and never has been, with developers being unable to cut code. Programmers do a good job with what they are given. It just happens that what they are given (the software requirements – user stories, whatever…) aren’t very good. Programmers don’t bother going back to the business and asking for something better, because they don’t get it, so they become resigned and get on with doing the job as best they can.

Agile delivery works fine. But user stories can be just plain silly. Just because it’s hard to define a good software requirement does not mean you don’t have to do it. If a user story isn’t properly fleshed out, you will find yourself trying to get to the details in programming time, not in investigation time – and that is wasteful and very expensive. It is going to lead to a lot of frustration.

‘Make things as simple as possible, but no simpler’. I wish I’d said that, but I’m just quoting it. (Apparently it wasn’t Einstein.) User stories with no structure, user stories that have no sense of wider context, are just too simple to be relied upon in anger. Hey, it’s not the delivery team that’s broken, it’s the requirements team. It always has been, and it still is.

User stories are a technique that in the hands of a good analyst are going to give the business a nice warm feeling that they are participating in the process. That’s a good thing. That’s a great thing. But you still need the analyst. This is not a process that can be de-skilled. It just can’t.

As Alistair Cockburn puts it “it’s much easier to write user story tags on index cards [then apply use cases] and let the project blow up later.” Agile project fail all the time. Practitioners claim failure is a kind of success. No, failure is failure. There’s no silver bullet, that’s true, there’s a whole box of silver bullets, and they only work when they are applied in a coordinated manner. Read: http://alistair.cockburn.us/Why+I+still+use+use+cases

Tags: , , , ,
Posted in Big picture | No Comments »

Humpty Dumpty putting it all back together again

May 24th, 2010

Say you are a Scrummaster walking along, minding your own business, and you come across a pile of user stories lying on the pavement. You pick the first one up, then the second one, then the whole pile of them and get yourself a stick of glue and begin to paste the stories together, hoping to get a view of the whole that ties all these stories together.

Or, imagine for a minute that these user stories are instead pieces of a jigsaw puzzle and it’s your job to make them into a big picture. The problem is that somebody has lost the box – you don’t know what the finished picture is supposed to look like. Suppose you use up all the pieces, but there’s something wrong. The person who lost the box, also lost some of the pieces.

What I’m talking about really is stories at different levels of decomposition; the hierarchy of stories, the project, release, iteration, of stories. If we haven’t got the project stories, we can’t make much sense of the lower level stories because we are unsure how the parts are supposed to hang together. If we have the project stories, that’s a different thing because we can break them down into lower levels that can actually be built in an iteration.

So we are agreed then that project stories break down into lower level stories, and it’s pretty straightforward to do that, but it’s still really important to make a picture of how those stories are related (their hierarchy of decomposition), because if we don’t know that, it’s just like having a smashed up humpty-dumpty at the bottom of the wall, and putting him back together again is just not going to happen.

Tags: , , ,
Posted in Storytime | 1 Comment »

How big is the elephant?

May 24th, 2010

A colleague of mine likes to ask the question “how do you eat an elephant?” The answer is “one mouthful at a time”, which isn’t really that funny, but it’s supposed to illustrate the Agile principle of ‘baby steps’. It kind of reminds me of an episode of the Simpsons where Homer is determined to eat this massive steak, and if he does it, he gets the steak for free. At least the restaurant tells him the steak is 16lbs. so he knows what he’s letting himself in for – kind of. Where am I going with this?

With an Agile project, we suspect we’re looking at a big steak, and we’re going to break it down and eat it bit by bit, but we have no idea how long we’re going to be at it, because we don’t know how big the steak was in the first place. Now say you had eaten a 4 pound steak before and you knew what that was like. If you set yourself up to eat a 16 pounder, you’d probably not eat for a few days beforehand to work up an appetite. You would at least have an idea about what you were letting yourself in for. But with Agile, nobody is saying how big the steak is. Nobody knows. Couldn’t somebody at least weigh it? OK, so maybe some of that weight is bone and some is fat and we don’t have to eat that, but it would be really nice to just have some kind of ball park figure. Know what I mean? Otherwise I’m not sure I want to get involved with this competition. I don’t need to know everything about that steak, but I’d be very grateful for a head’s up.

Maybe the analogy doesn’t hold. Say you haven’t got enough room in the fridge. Maybe I’ll just eat until you tell me I’ve eaten enough and can stop. Afterall, you are paying me to eat the steak (thanks). But you are not going to know whether I’ve eaten enough until you see it for yourself. What happens if while I’m busy eating the steak, you realise you really wanted me to have the chicken. Look, I can’t give you back the steak, that part of it is already eaten. What happens if I just eat whatever comes out of the fridge first, say it’s some bone (I’m going to find that pretty hard) or it’s some fat (pretty tasty maybe, but of no nutritional value). It’s a minefield. Perhaps I’ve taken this analogy as far as it will go. What I’m trying to say is I’d like to know what’s on the menu. That’s sensible. How do we make that happen in Agile? It’s not going to happen in Agile Delivery, that’s too late, it has to happen in Agile Requirements. Give me accuracy – precision can wait.

Tags: , , ,
Posted in Big picture | 1 Comment »

Pulp Fiction

May 24th, 2010

Last month I sat in on a two day user story workshop in a big insurance company, with 9 (!) analysts responsible for writing user stories. I saw the stories they were writing and didn’t think very much of them. The project they were trying to feed stories into had no sense of the customer, no sense of the product they were trying to sell, no sense of the overall purpose of the project. It was a mess. And this team had a backlog, but no idea of whether the stories in the backlog were ‘implementable’ in a release/iteration sense. There was no hierarchy, no project stories, no sense of the big picture. Just a lot of mush. The team was suffering from analysis paralysis! Or maybe I should call it ‘writer’s block’.

Everybody is a storyteller. Everybody has a voice, and wants to be heard. That’s how it should be. It’s also true that some people tell better stories than others, you meet them at parties, or conferences; people other people enjoy listening to. The master story teller is really an Agile way of describing the business analyst. The master story teller goes all around the village collecting everybody’s stories. Some of them are the same, some are parts of stories, some people can’t remember how the story ends. It’s like that with stories. The master story teller brings them all together and makes sense out of them. He then tells the story back to the village, and depending on how the story goes down, he might change it or leave it just as it is. Not everybody can be a master story teller; it’s a vocation. First of all you have to be a good listener, then you have to drill down into the essence of the story to find out what it’s really about, and finally you have to put all these disparate story threads together to come up with one compelling narrative. I think that’s a good way to understand what the business analyst does on an Agile project. He’s the keeper of the big story and he’s able to drill down into the story to come up with the detail when one of his more attentive listeners really wants to know.

Tags: ,
Posted in Storytime | No Comments »

Dogmatic Agile – discuss…

May 24th, 2010

Does Agile really work? Well, it works for some people. In reality any project will deliver successfully with any methodology if the people on the team are really motivated and talented. So if a great coach comes in and and gets the job done using Agile the conclusion is made ‘hey, this Agile thing is effective!’ Then the coach goes off to pastures new and the team tries to do it themselves and the project falls apart. So the Agile community talk about knowledge transfer and cultural change as being the key. And so it is. But cultural change is really difficult – and most people are average, by definition, and they like to be told what to do. People feel comfortable being told what to do. That’s reality. What do we do about that?

So Agile, a great set of ideas, becomes a dogma in itself when people stop thinking critically for themselves. ‘We can’t do that – it’s not Agile.’ So what?  Then we get dogmatic Agile – could there be a greater contradiction? There are lots of ‘Agile’ projects that fail. The community does a really nice trick here by saying ‘failure is success’. And in a way that is right, it’s better to fail early then fail late. If the project fails under Agile principles, we assume it would have failed under Waterfall, only later and costing more. This may be true, or it may not. We can’t tell. What we can say, is given there was a reasonable business case for the project, and given the project really would have delivered measureable business value, the fact it failed is a bad thing.

Tags: , , , , ,
Posted in Evolutionary Agile | No Comments »

Estimation, Guesses and Lies

May 24th, 2010

I’m not talking about estimation of user stories during planning using ‘planning poker’. I’m talking about the big picture estimation during feasibility (I prefer the term ‘contemplation).The boss says ‘good idea, how much is it going to cost?’ Is this question supposed to go away? ‘Listen boss, just trust me, we’ll get started and see how we go, and if we don’t make any progress, just cancel the project.’ Fine if that’s the kind of company you work for. I’ve never worked for anybody who ever thought like that. Perhaps that’s a pity, but it’s my experience. No, they want to know how much it is going to cost upfront and it doesn’t matter that it’s it’s a pile of hooey. Everybody knows the number has effectively been plucked out of the air, and somehow it becomes the budget, and everybody’s disappointed when the real project bears no relationship to the estimate. Odd, a number based on a guess is wrong – who would have thought it. But it is still the case that if that is what the accountant types want, that is what you have to give them. So, instead of a completely random guess, wouldn’t you prefer to base the guess on something so instead of a wild guess it was an educated (OK, an ‘informed’ guess). Yes it’s hard, but that doesn’t mean it’s impossible, nor does it mean we can ignore it. It just means it’s hard. But, it is possible to get better at hard things – that’s why people practice at things. Nothing worth doing is easy – remember that old saying. I hated it when my mother told me that – but that doesn’t make it wrong.

So it could be that your estimates are today an illusion – they represent an illusion of control. In reality the business would be happier if they could keep their illusions of control and they’d be a whole lot happier if the illusions became more concrete over time. OK, so to start with estimates are rubbish, but it is possible that if a reasonable process were defined, and refined iteratively, with a meaningful feedback loop from projects completed, we could get better at it. This doesn’t mean years of analysis, we’re past that, but why can’t we have an accurate representation of what we want without cluttering it all up with mis-leading precision?

Human history is littered with stuff we don’t know, then we figured it out, and then we realised it was just a question of us not knowing – yet.

Tags: , , , , ,
Posted in Big picture | No Comments »

Café Culture

May 24th, 2010

Remember when they changed the alcohol laws and expected the British would start drinking like our European neighbours? Have you been into your city centre on a Friday night recently? It didn’t happen. It might happen but cultural change takes a long time.

If we are going to wait around for fundamental business cultural change before Agile can work it could be a really long wait. People will lose patience, the next big thing will come along, and everybody will jump on that bandwagon heading nowhere fast. No, no, no, there’s too much that is really good about Agile and what works – works, so let’s leave it alone. What I’m talking about is Agile Requirements – that’s rigour around user stories. Stories don’t belong in Delivery, they’re an input to Delivery, they’re the ‘requirements’, and they belong to the business. Yes, this goes against the status quo – all well – that’s what makes for a good conversation – right?

Does this violate the Agile principle of ‘cross-functional teams’. No, I’ve already said that what’s in Agile Delivery works and stays as it is. I’m just saying that it isn’t efficient to show up on day one of a Scrum for a planning meeting and expect all these expensive people to start writing stories from scratch, or worse yet, trying to make sense of a big mash-up of stories and fragments before they can get to work building something. It’s demoralising and it’s counter-intuitive. It doesn’t work. You show up on day one, you want some good quality stories to get your teeth into. That’s common sense – maybe not common practice, but it’s common sense.

I’m going to make the distinction between Agile Requirements(AR) and Agile Delivery(AD). So, to be clear, part of the story telling has to happen outside of AD. Once the iteration is underway, the two work together, but AR outputs stories and AD takes them as an input. This has a lot of ramifications – and they’re all good.

Tags: , , , , , , ,
Posted in Evolutionary Agile | No Comments »

Agile Stress

May 24th, 2010

Why do people choose Agile? Is it because they are desperate? On the one hand Agile seems pretty straightforward – it’s a method that gives development teams more say in how they build software. On the other hand, Agile is hard because business people have to change the way they work coupled with needing a lot more trust. The business has to give up the illusion of control, and go for real control over a smaller planning window. They have to move away from the idea of fixed price/scope/timeline and embrace time and materials. No wonder management feel insecure. Wouldn’t you? And even though the Agile coaching community make it clear this is what is required, the business doesn’t want to hear it. It seems to me that people only hear what they are ready to hear – no matter how clearly you say something. That’s just the way it is.

Tags: , , , , ,
Posted in Big picture | No Comments »

Newer Entries »