Agile Stories

This Site Has Moved!

2009-10-11T16:25:00.000+01:00

I've now set up a new site at http://www.agileproducts.com, articles from this site have moved there.

Why You Should Care About Marketing

2009-02-05T21:00:00.008Z

Mention the word ‘marketing’ to to a group of techies and it is a fair bet that they will respond with some derision. To many I.T. types the marketing department epitomises the sort of soft, nebulous, arts-graduatey world from which we hard science types have long been culturally divided. Sure, they have some pretty girls over there, but they never talk to us, and the questions we get from them are so dumb. In a rational world they’d all be fired and sent back to school to learn some real skills.

This is a stupid attitude. Here are some reasons why you should care about marketing:

1) It keeps you in a job. The clue is in the name. Marketing is about creating and sustaining a market for your products. Without that, you’ve got nothing. It doesn’t matter how elegant your code refactoring is, or how quickly your application runs, or how cool your new design is; If nobody knows about your product and it fails to make any money then you’re on a one-way trip to the unemployment office.

2) It helps you do your job better. I’ve sometimes heard developers say that Agile development is about ‘getting the business to understand IT’, and that’s true, but it’s also about getting I.T. to understand the business. Knowing how your non-technical colleagues think and what they are trying to achieve will enable you to collaborate more successfully and fulfil their needs better. In the age of outsourcing these sort of softer skills can give you a crucial edge over the guy in Chennai.

3) You can help them do their job. You may have things to learn about business, but your business colleagues have things to learn about technology, and you can help. The web, in particular can represent a perfect marriage between marketing and I.T., but in a lot of organisations the marketing team may still run along fairly traditional lines and not be aware of the opportunities that are out there. Do they know about all the powerful campaign tracking tools offered by even a simple system like Google Analytics? Are they familiar with RSS? Have they heard of the new social networking craze taking the West Coast by storm? Perhaps you should tell them about it.

4) It’s interesting. No, really, it is. Who are your customers? Why might they like to buy your product? How do you tell them about it? What might they pay for it? How would you keep them? What new ideas can you try? What is it that makes you love brands like Apple or Google, and not (say) Microsoft? Who knows, if you figure these things out it could be your first step to running your own cool tech company.

5) You might get to talk to girls. I’m kidding. Obviously. But still, take a look around your office… *

Convinced? Here’s a few sites that are sometimes worth reading:
Advertising Age
Marketing Week
New Media Age
Media Guardian
Google Blog

* Edit: Feedback from female tech readers reminds me to stress the purely professional benefits of engaging with colleagues from other disciplines. Also that it affords greater opportunities to meet men who are popular and good at sports.

Iterative Design Change

2009-01-27T20:36:00.012Z

"Linux will never make any meaningful headway into the desktop," argues a recent item in IT paper The Register. I can scarcely think of a duller subject than computer operating systems, but on reflection I thought that this piece and the comments which accompanied it had something interesting to say about product design.

The essence of the argument is that most ordinary computer users simply want to get their job done, are familiar with Windows, and do not care about the sort of performance or security issues which attract techies to alternatives. The discussion which followed it largely divided into those who agreed, and those who felt users could or should be educated into using other systems. I thought one particularly insightful comment was this:

I wonder how many of the problems Microsoft had with Vista and market acceptance are not so much the resource usage (which only really the techies care about, and you probably wouldn't really notice anything in day-to-day usage if you've just bought a new computer three times as powerful as your old one), but the "everyday" users clamouring,

"Aargh, how do I foo in this one!" "I can't find the bar anywhere!" "They've completely changed quux!" &etc. to "I want my XP back!"

Watching non-technical users being exposed to new systems is an education. Techies have a tendency to go, "oh, it's not there any more", grumble a bit about relentless UI fiddling, then go menu spelunking until they've found what they need, no more worries. Normal people, on the other hand, are more apt to freeze, stare blankly at the screen, and murmur, "I want the old version back."

It’s no secret that Windows Vista has performed disappointingly in the market and this could be one reason why. I avoided buying a Vista machine myself because I’d heard horror stories about needing a supercomputer to run it, but also because Windows XP does everything I need it to, and at this point I don’t particularly care if they never release another version ever again. However if Microsoft never tried to introduce innovations then they’d be a considerably less successful business and Windows would still look like this:

It is an issue familiar to most of us who have ever tried to develop a product with an existing customer base. On the one hand, you don’t want to alienate your users by changing things with which they are comfortable. On the other, you presumably have sound business reasons for making a change and users generally find it hard to imagine how things might be better unless you show them.

One neat attempt to address this dilemma was the recent transition to ‘the new Facebook’. At first users saw a link on the existing Facebook homepage inviting them to preview the new design. Then the new design was set as the default, with an option to switch back to the old version. Finally ‘the new Facebook’ became ‘the only Facebook’. This still caused some consternation amongst users – but a few months down the line, who remembers the ‘old’ Facebook?

The idea of design change by gradual evolution is hardly new and has long been used by the likes of Amazon and eBay. Unfortunately it isn’t an option open to Microsoft, they can’t release dozens of new versions of Windows with small changes from one to the next. With web based products there are still times when a total relaunch is called for, but generally speaking the ability to change a little and often is a unique advantage, and of course it is an approach ideally suited to iterative, agile development methods. You can alter the product a bit at a time, taking your existing users with you whilst making it more attractive to new ones, and react to feedback along the way. A traditional waterfall approach is much more likely to lead to a big all-in-one redesign, and the risk that your product will become the new Vista, or even the new New Coke.

Book: Once You're Lucky, Twice You're Good: The Rebirth of Silicon Valley and Web 2.0

2008-12-13T18:42:00.012Z

Sarah Lacy begins her fascinating journey through the creation of second-wave, 'Web 2.0' companies amidst the smouldering wreckage of the 'Web 1.0' dot-com crash, recounting how entrepreneurs and investors learned from their mistakes and rebuilt the world of online business. I actually read the U.K. edition with the rather less descriptive title The Stories of Facebook, YouTube & MySpace: The people, the hype and the deals behind the giants of Web 2.0.

Sarah clearly has a fantastic 'friend list', and has spent a lot of time in the company of leading web industry figures like PayPal and Slide founder Max Levchin, Digg's Kevin Rose and Mark Zuckerberg of Facebook fame. This isn't a book about technology, nor a dry book of business theory, rather it uses human stories and anecdotes to deliver insights into the Silicon Valley scene of startups, web business models and the the venture capital industry.

A few of the things that stood out for me:

The book is a powerful argument for the benefits of economic clustering. These guys all know each other, invest in each other's companies and feed off each other's ideas. That's one of the main reasons these businesses emerge from Palo Alto and not Peterborough.

The founders are incredibly driven individuals, working obsessively in pursuit of their dreams. I don't think this is just a US thing, but I do think it explains why people working 9-5 for a modest paycheque from MegaCorps Inc. do not come up with 'the Facebook of [insert chosen market here]'. The title of the book refers to the belief that to really prove yourself in the Valley you have to build not one but two $1Bn companies.

I hadn't really appreciated just how much open source technologies have transformed the economics of web startups. Making money is still hard, of course, but the barriers to entry have been lowered dramatically, and many web 2.0 firms have built profitable businesses before needing any cash from venture capitalists. It makes me wonder yet again why my previous employer insisted on building everything using expensive heavy metal.

As a book about business and the internet this perhaps isn't a title which will attract admirers on the tube, but it's a terrific read for anyone who works in or is interested in the industry.

I'm now waiting for someone to write a book about twitter using paragraphs of no more than 140 characters apiece.

Buy from amazon.com
Buy the UK edition from amazon.co.uk

Life In The Iron Triangle

2008-12-01T14:35:00.001Z

Somewhere, over the rainbow, there is a magical universe where projects always deliver on time, on budget, and to specification.

Unfortunately, not many of us visit that world too often. We spend most of our time in a place where things go wrong. Tasks take longer than they were supposed to. You discover requirements you had not anticipated. The hardware doesn't show up. The designer falls off her snowboard and breaks both arms. Enter our familiar friend, the Iron Triangle:

Schedule, Cost and Scope. You can get up to two of these back on track, but not all three. You can still get everything you wanted when you wanted it, but only if you hire more effort. Or you can keep to the same spend, at the expense of fewer features. Usually there will be some compromise adjustment of all three. We've all been there.

In a waterfall development the procedure will be to have a replanning meeting or initate a 'change request' process. You adjust the requirements up here, then adjust the development estimate down there, which then alters the testing schedule.. a series of interlinked changes ripple up-and-down a Gantt chart covering a period of many months. And then the following week something else happens and you go through the whole exercise again..

This process can become pretty painful. I have seen projects whose entire energy winds up being absorbed into this planning spiral. I have seen projects run for an entire year, and get as little as two weeks' actual development done. I've even seen projects abandoned completely because they were no longer worth the candle.

Agile Development fixes all of this though, right? By planning a little and often and being flexible you take the heat right out of these decisions, projects proceed without pain and there are no nasty surprises.

Yeah, right.

When Agile Projects Go Bad

Developing using an agile methodology does not change the fundamental objective - you are still attempting to develop a product with certain characteristics, on a particular timescale, using a given budget. And while you may avoid months of 'analysis-paralysis', or dozens of tedious and demoralising change-request meetings, ultimately the same problem often arises - it becomes clear you aren't going to be able to release what you wanted on time and budget. Why does this happen, and what do you do about it?

The first part is easy, it happens because we are human. Nobody can look at a project of any complexity, anticipate all problems involved, and accurately estimate what it will take to overcome them. By rejecting upfront specifications and planning agile explicitly acknowledges this. However agile skeptics would argue that this simply creates a vacuum, allowing for open-ended projects which drift along without proper control - and they are absolutely right.

One of the most common problems with agile projects is that the team keep discovering interesting new features to build, or elegant code refactorings to undertake, or simply keep changing things because they can... and x months later find they have spent the budget without producing a market-ready product. That doesn't have to happen too many times before companies decide that agile ain't working, and return to waterfall development, or try fixed-bid contracts, or whatever.

Keeping on Track

So how do you avoid this? Well, look again at the Iron Triangle. It may be a triangle, but it isn't a very equilateral one. In many situations 'time' and 'cost' are quite close to being the same thing - the spend is a function of how many man-hours are put into the project. Now if there is one thing companies hate it is losing control of costs, which implies that you should try to keep to schedule. In which case the thing which must give is scope - the angle which agile projects often seem to be worst at governing.

However that need not be the case. The thing to do is start with a very clear vision of how the overall product should look, what the absolute must-have features are, and make sure that you build them first. Suppose you are building a photo-sharing website like Flickr. You need a site where people can create an account, upload photos, view them, tag them with search terms, and search. That's a minimum, without which there is no product. Now what may happen is that you put some really cool, 'web 2.0' photo-networking feature in your prototype, your test users love it, the team throw themselves into building it - and totally neglect some boring fundamentals like user registration. Come the expected end-date of the project, you have half a photosharing site with one really exciting feature, but you can't launch or do anything with it. You have no choice but to either spend more money or give up, and your bosses aren't happy.

In contrast, if you keep your eyes on the prize and try to ensure that you have a shippable, if minimal product by the desired date, then the engineering team have done their job. Sure, it may be the case that without the cool extra feature you don't feel able to take the product to market - but it's a business-based decision. Perhaps you will do a soft-launch, or a closed beta. Perhaps you get a little more funding to add that extra killer feature on top. You're in control of events, and in a strong position to choose.

This then, is the way I believe you can deal with the tyranny of the iron triangle:

Start with a clear product vision
Develop iteratively, most important things first
Try to hit the end date, and thus control costs
Adjust scope to make this possible

Being able to deal with the day-to-day detail of changing stories without losing sight on the end vision is one of the most important parts of the Product Owner's job, requiring a strong sense of prorities. At the same time the engineering team need to keep the business objective in mind when deciding how much refactoring they can afford to do. On reflection a lot of this is about remembering the macroscopic project goal and not getting lost in the microscopic mechanics. Ye cannae change the laws of physics. But if you look up often enough you're a lot less likely to get smacked on the head by an apple.

Breaking Stories Down

2008-11-22T15:55:00.000Z

When I've talked to various people about the art of writing stories they often say that they have trouble breaking them down into small enough pieces. One former colleague who now works for a gaming company told me that their stories were not far off being 'build a game'. I'm not sure why this is. I think maybe people know that a story should describe a discrete piece of functionality, and deliver value to a user, but they come up with things in terms of a traditional end-to-end use case, like 'user buys a book'.

Now, 'user buys a book' is a huge epic of a story. On any bookstore site you've got the page which displays information about the book, you've got several screens of complex shopping cart functionality, you've got email receipts, hooks into the backoffice, etc. Starting at the beginning, your first story might be 'Show book information'. Suppose your UI prototype is this screenshot from Amazon:

There's an awful lot going on just on that page. What's the most basic information you could include in 'Show Book Information'? How about the title, author, and perhaps the front cover image? That will do for our first story. I would actually photoshop my screenshot and stick it to the front of the story card:

While my acceptance criteria would look like this:

There's a number of things to note here. I started the acceptance script with 'go directly to the url..'. That's because at this early stage of the project I'm presuming there's no way to search or browse to that page. I didn't include price in this basic initial set of information. You might think that's fairly fundamental, but my guess would be that the price is stored in a more complex piece of the backend that we aren't talking to yet. I have included the cover image, assuming that is straightforward. These are all things I would know by talking to my developers. Adding the price would likely be my next story:

One temptation to avoid is putting dead links and buttons to things you haven't developed yet. It would be no work to add the button which says 'add to shopping basket' at this stage - but it wouldn't go anywhere. Doing this violates the principle of always having shippable software. Suppose we decide we have enough to beta the site as a kind of catalogue, without purchasing facilities - in that case we don't want buttons to non-existent ecommerce sequences to appear. That may seem pretty obvious - but it's quite easy to imagine buttons like 'Tell A Friend' or 'Add to Wish List' appearing on a live release before anyone remembers those features didn't make the cut. I'd add the button when I do the story 'Add book to Shopping Cart':

I think a lot of people might say here that I'm going too far, and these stories are too small. For a lot of situations they might be, I used to produce stories this size when working with teams whose iterations were only 1 week long. But I think the basic principle is sound. You can almost always break things down - If there's a tangible result and you can establish good acceptance criteria then it can be a story.

The Trouble With Release-Scale Estimation

2008-11-16T15:40:00.021Z

With practice most agile teams get quite good at estimating individual stories, and hence at iteration planning.

However trying to extend the same ideas to the backlog and release planning often results in something like this...

Eventually (and possibly with the aid of a gun to their head) the team may come up with some numbers. Which then get used..

Project managers generally need release-scale estimates, and a lot of thought and effort has been expended in coming up with methods to provide them. Many, in the opinion of this author, are just a bunch of hocus pocus. Some work well enough within a team that understand their limitations and the assumptions that went into them. But when people start drawing charts and quoting story-point totals and 'burn rates' out of context then they're generally talking complete nonsense.

It remains a fundamental fact that you cannot accurately estimate requirements which aren't accurately specified - and if you are doing agile development and requirements are still in the form of vague epics on the backlog then they are not, by definition, accurately specified. If future requirements have to be worked out down to detail then you're no longer doing agile development - you're back in the waterfall world of the upfront specification with all the problems that implies.

So what's the answer? Really, the best answer is not to worry about it. If you prioritise properly, build the essentials first and aim for coherent on-time releases you perhaps don't need to bother with burn charts and all that jazz. Of course, some sort of estimation is still required, and there you can't beat experience and time-honoured tooth-sucking skills...

Product Manager vs Business Analyst

2008-11-10T19:06:00.006Z

It's not often I read something on the Silicon Valley Product Group blog that I don't agree with, but as a former analyst by trade I wasn't too sure about this recent article on the roles of product manager versus business analyst.

The thrust of the argument seems to be that 'Business Analyst' is essentially a legacy role which overlaps with and confuses the responsibilties of the agile product owner. On reflection, I think that may be true - a good product owner who has time to focus on the development, engages with detail and undertstands technology probably doesn't need a business analyst.

And there's your problem right there. In my experience at least few product owners are able to fulfil those criteria. They're often appointed to a project from the existing 'business' side, sometimes with little prior technology knowledge. They may have wider responsibilties - departments to run, conferences to attend, 'offline' businesses to oversee. They may not even be co-located. In those situations a good analyst is invaluable, guiding the product owner through the maze of a technology project, being there every day to deal with the developers, focusing on details.

Similarly, developers should have the communication skills necessary to work with the business, but we know this isn't always the case, particularly in the age of outsourcing. The analyst's ability to 'speak both languages' is still very useful. Of course there are analysts and analysts - diligently beavering away on volumninous documentation isn't too relevant in agile development, the agile analyst needs to be a flexible and creative decision-maker.

As I said, a proper product owner as defined by the agile literature probably doesn't need an analyst. But in a world where most organizations can't simply reorganise to suit the ideal then there is still room for the role.

Story Acceptance Criteria: Say What You See

2008-11-07T21:07:00.004Z

The real meat of a user story is in the acceptance criteria. A lot of the examples you see out there look a bit like this, taken from a Mike Cohn presentation:

In the situations where I have worked there's probably a bit too much going on there for one story, but in any event I wouldn't write the acceptance criteria that way. My version would look much more like a UAT script:

That's a much more detailed description of what the story should do. It's more effort to write, but for me when I'm writing the story is when I want to put the effort in, and when I have all the information in my head. Come the end of the iteration, I have a pile of stories waiting to be signed off and I don't want to spending time figuring out how to test 'verify cancellation' or whatever.

This type of 'do this - see that' script reminds me of the long-running British TV show Catchphrase, and host Roy Walker's constant exhortation to 'say what you see'.

Articles

2008-10-01T17:05:00.014+01:00

Writing User Stories

Project Management and Planning

Misc

About This Site

2008-10-01T01:21:00.005+01:00

About Me
I have spent several years building web products, mainly in the media/publishing industry, and began using agile development methods after training from Thoughtworks. I started this site to fill a bit of time between jobs, and share some of my experiences. Although the site is entitled 'Agile Stories' I would never describe myself as any kind of agile 'evangelist', rather a pragmatist who believes agile methods have a lot to offer in the important business of getting products built.

About Agile Stories
I enjoy writing user stories, which I find a very natural and straightforward way to design products. However it seems that a lot of people find them more difficult, and there appears to be relatively little published about them other than Mike Cohn's well-known book. This site aims to make a very small contribution to filling that gap, and extends to related non-technical aspects of agile web development such as product and project management.

Contact Me: agilestories@googlemail.com