Coaching – the difference between stories and tasks

My first foray into operating as an Atern coach has been more enlightening and challenging than I had imagined.

A while ago, I started working with a team implementing changes to comply with two separate pieces of legislation. Typically, the project had started late, and time was running out. So you’d think that, with the pressure on, they would be looking for every bit of contingency they could find, right? And that they would be rigorously planning their scope and prioritising their requirements to generate some feature-contingency? And for those of you thinking “it’s regulatory, of course the requirements are all Must Have”, you’re not necessarily correct. More on that another time, perhaps.

But looking at the Requirements List, it was clear that the team had written ‘stories’ that more closely resembled a list of tasks. There were very few actual business requirements. So I had a short workshop with the Project Manager, the Business Ambassador and the Business Analyst in which I showed them the difference between a requirement and a task [I shouldn’t have to explain that to a BA], and we worked through a few examples and reworded them. I think they understood why user stories are structured that way. And yet….

I later sat down with the project manager and we spoke about it. His belief was that Agile is suited only to what he refers to as ‘green field’ projects. And that end-date driven projects cannot be agile. And that the developers cannot estimate without certainty about the solution. Those are his beliefs! And given those beliefs, it is hardly surprising that the team were allowed to specify the solution in some detail at the start of the project.

The implications of this should be obvious to you. They have removed from their project two things we as agilists firmly believe in – business engagement and feature-contingency. Their Prioritised Requirements List is essentially a list of the Must Have things to be done, so there is fixed scope as well as time and cost, and with those ‘requirements’ actually specifying the work to be done, the business have no further role to play in evolving the solution to meet their requirements. This was now a waterfall project, with a sizeable risk.

I have my work cut out!

Advertisements

About aterny

Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
This entry was posted in Agile and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s