Archive for the ‘Storytime’ Category

Feeding the Story Monster

Friday, November 19th, 2010

Many things are taken for granted with Agile. One of those things is that there is a product owner who:

  • Is co-located
  • Is always available
  • Knows everything
  • Can make decisions
  • Can prioritise
  • Knows how to write user stories
  • Can see the ‘wood for the trees’ (is comfortable with abstraction)
  • Can imagine a future way of working

A person with these qualities does not exist on the project I’m working on at the moment. I doubt anybody’s working on a project with somebody like that; if you are – work hard to get a contract extension because that’s as good as it gets.

Product owners are not requirements engineers, nor do they want to be. If we, as the delivery team, sit back and wait for a prioritised and properly sized set of stories to arrive in time for our planning game, we are going to be frustrated. This is a ‘push’ model; the requirements people push us the stories. What do we do if the stories aren’t coming through? Well, then we have to use a ‘pull’ model to get the stories into the planning game.

The business knows what they want; up to a point. As far as they are concerned, they have told us what they want. It’s not enough for delivery to get on and build it, but it’s certainly a good start. We say ‘where are the requirements?’ They say ‘you know what we want.’ So what’s the problem? The problem is the devil is in the detail.

If we don’t have enough detail, we need to model the scenarios, look at the data, consider the alternatives, come up with our best recommendation of how the system should behave and then present the business with the findings. So, a pull approach to getting stories into the backlog, when the cupboard is looking bare, is you do the modelling and scenario work upfront, then you have a conversation and then you get agreement to feed the sprint.

The sprint is a hungry story monster that needs to be constantly fed with good quality stories. The business can get bogged down in stories, value, priorities, acceptance criteria and release plans. It’s hard. The analysts in the delivery team need to offer the business analysts/product owners a hand – whatever it takes to get the job done.

Posted in Storytime | No Comments »

Comfort Level

Thursday, September 23rd, 2010

I’ve already said that my job is to feed the programmers with work in the form of stories. The stories are designed to fit into a one week unit of work. This is useful because it shows that progress is being made. But it’s hard to tailor iteration stories to a week, and it’s even harder when the iteration story is tricky to understand in the broader context of the code to support the full user requirement. I have to understand how the small story fits into the big story – otherwise I can’t be sure the team is building something of business value – I can’t map it back. So, that’s a priority and that’s now done. I have only been able to get it verified lightly by the solution designer, architects and a couple of BA friends. But, no mattter, it’s still helpful and provides a kind of ‘table of contents’ into the wider system. I also did a surreptious end-to-end activity model. I broke it up into sub-activities based on the kind of jobs people actually do now. Activity modelling really works to show how user stories are called sequential to satisfy a particular workflow. And it’s fast. It’s pretty obvious on a high level and the high level is sufficient for this exercise.

Posted in Storytime | No Comments »

Blogging vs. Clogging

Thursday, September 23rd, 2010

I’ve discovered it’s hard to reflect and write on something that’s going on while doing that thing at the same time. I’m working on a big project to build a digital media warehouse covering decades of material. It’s a fascinating project with lots of talented people working to scale Agile and deliver incrementally production tools with demonstrateable advantages to the way new programmes are edited.

My job, as a technical analyst, is to quality control the stories arriving from the requirements team. The ‘stories’ themselves are held as issues in Jira. This illustrates the level at which the stories are broken down, as they are meant to be groomed to fit a single iteration, where an iteration is only one week. So, the stories are low level, and don’t represent business value in themselves. The stories are decomposed from higher user stories, but the link to the complete user stories has not been maintained. My job is to try and make sense of the existing backlog and try to map iteration stories onto the parent story. The other thing I’m tasked with, the over-riding priority, is to get enough stories into the sprint planning meeting to ensure the programmers are fully occupied; the aim being to have visibility over a four week period of upcoming work.

This is a challenging task, and why I’ve been too pre-occupied to write. I know that is no excuse, if somebody writes on a blog, they need to keep it up, or people will lose interest. This is a different style of blog then, a kind of ‘considered’ blog where I need more time to write anything I really want to say. So it’s a ‘clog. That’s it – I’ve become a clogger! After all people in clogs can’t run very fast (I don’t think…)

Posted in Storytime | No Comments »

A New Definition of ‘Epic’?

Wednesday, 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 »

Humpty Dumpty putting it all back together again

Monday, 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 »

Pulp Fiction

Monday, 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 »