www.thought-bubble.co.uk

This post is from allaboutagile.com by Kelly Waters.

Projects are a necessary evil 🙂 But necessary they are. Some people really feel the need to understand precisely what the project will cost and exactly long it will take. If this is the basis for investment, of course that’s a completely understandable feeling.

For years, traditional waterfall projects have been sold on the false pretense that projects are predictable. Plannable. Of course the reality is, projects are highly unpredictable, and – sadly – that’s why so many projects fail to meet expectations.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here:

User Stories. User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front.

As a guide for people writing User Stories, they can follow this basic construct:

As a [user role], I want to [goal], so I can [reason].

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

A software release may result from multiple iterations (or ‘Sprints’ in Scrum).

Sprint Planning is about planning what’s included in the next iteration.

Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered.

Release Planning is a very simple way of doing some top-down planning. Much less complex than a more traditional project plan on a Gantt-chart. Therefore much quicker to do. And, I would say, no more or less accurate.

Click here to see the full post.

This post is from mountaingoatsoftware.com by Mike Cohn.

I was asked recently how to go about writing user stories for a back-end financial system. This is an interesting example and is a question I get asked a lot, so I thought I should answer it here. This example brings up a couple of key interesting challenges:

• While there may be users of the system they are not often not direct users (i.e., with hands on the keyboard waiting for something to happen)
• The functionality is often larger than will fit in one iteration

So that we can deal with these challenges, let’s make up some more context for the example. Suppose our financial system takes in a lot of daily data and produces flat files that will be sent to banks and other partners at the end of the day. Some of the files are simple formats. Other files are in more involved formats with multiple record types within the file and possibly with multiple lines for some of the transactions. This would be a fairly standard batch-processing type application. I want to write user stories in the template I recommend in the book: As a , I want so that . So, let’s deal with these challenges in order and first try to figure out who the user will be in our stories? Given the context provided above the user, is probably a bank or business partner. This will let us write stories like “As a bank, I want…” It’s entirely possible that we will want to get more specific and sometimes write stories for more specific users:

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

Recently I saw a brief set of questions from Nokia to assess whether or not a team is ‘agile’.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

I recently described User Stories and the composition of a User Story Card – Card, Conversation and Confirmation.

I’m not really sure if you would consider this user story example to be good, bad or indifferent – I guess it depends what you’re used to – but here is an example nevertheless!

This is the front of the card.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

In a few entries on my blog, I have referred to Velocity and only briefly explained what it is. I think it’s about time I explain properly for those not familiar with it.

Velocity is terminology from the Scrum agile methodology and is basically the same concept as Earned Value in more traditional project management methods.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

One technique used by agile development teams is the idea of estimating product features using points. This has a few distinct advantages over estimating in physical units of time.

1. Estimating is very quick because it’s an intuitive estimate of a feature’s size.

2. An estimate in points indicates a feature’s size relative to another, and does not give the illusion of being precise.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

When I first encountered agile development, I found it hard to understand. Okay, I might not be the brightest person you’ve ever met! But I’m not stupid either, I think 🙂

There’s a myriad of different approaches, principles, methods and terms, all of which are characterised as ‘Agile’. And from my perspective, all this ‘noise’ makes agile software development sound far harder, far more scientific, and far more confusing than it really needs to be.

Click here to see the full post.