A problem that can often occur in planning poker is a stalemate situation - i.e. the same cards are played by each player for more than one round without a consensus being reached   more »

If you're involved in planning and managing software development read this book and it will alter your mind.   more »

so rare and in such high demand - you'll be lucky to get it for less than £70. The sign of a very, very good book I'd say   more »

If anyone plays a ? card this should be taken as an indication that they have something important to say and therefore should be given the floor first in that round...   more »

As part of what ever self organising means - and I accept that it’s widely debated - surely a team would be expected to provide some statement relating to its function that allows its co-operatives to have confidence in it.   more »

Once a User Story has been added its possible to start entering Confirmation notes immediately   more »

Once a User Story has been added its possible to start entering Conversation notes immediately   more »

With an Agile approach testing becomes a constant activity that is all about asking a whole range of questions and keeping them front of mind at all times   more »

As a general rule in planning its good to employ practices that mitigate against presumption influencing reality and this is well illustrated by the success that Planning Poker can bring to the software development process.   more »

Introducing the daily stand-up to a team has its challenges so this article offers advice on how to facilitate that change and make the scrum more effective.   more »

In previous articles in this series I’ve discussed how to pull together a simple agile approach based around Card Conversation Confirmation. In part 5 I want to illustrate how this can be introduced in a traditional lifecycle.   more »

So what is it that is so complex about answering this question? Well - maybe the traditional project management role needs to be adapted to fit the agile world - the old dog needs to learn new tricks perhaps.   more »

If a team wants to become agile it must have a reason for wanting to do so - there must be something not going to plan - something broken about the process - or just a desire to perform better - the team can only know if this is a success by measuring it - just a little.   more »

Rizwan.Tayabali recently posted a blog on waterfall v agile which I interpreted very much as process v people.   more »

From day 1 – why do you decide to become agile – because it will bring benefits – how will you know these have been realised – you will need to measure them – which should be straight forward assuming its some measurement you’re not happy with that made you decide to become agile to fix it in the first place.   more »

I would point out that the product backlog isn't much more than a list - and is only going to be as complicated as you make it   more »

I'll be planning to release the first full version in late June early July and this will contain the first deployment from the 'Add work flow basics to CCC' project. Before I start the development I'll post so that you can see what I've got in my sprint and why I left some things until later.   more »

A bux fix has been released on the beta version of CardConversationConfirmation.com today.   more »

Next comes Work Flow; the processes or the stages, indeed the lifecycle of a User Story from its initial conception to its deployment on the production platform.   more »

Using structured user stories in the form AS A, I WANT TO and SO THAT offers a greater agile benefit to the data that represents the requirements without adding in too much additional data to supply the structure - it gets the balance just right on ceremony.   more »

After adding a new project or selecting an existing one the screen prompts the user to add the first user story.   more »

This weekend I've released the first beta version of my new agile tool at CardConversationConfirmation.com - and its completely FREE to use.   more »

... a challenge when there are dependancies on another team, in another organisation, who are not running an agile project. How should these types of dependancies be managed effectively while maintaining an agile sprint orientated approach at home?   more »

There are many software development teams who are working in an ad-hoc way and are desperately looking for improvements in the processes that define their working lives and their business - here will be benefits for the developers, the management and the customer.   more »

Card Conversation Confirmation is described by Ron Jeffries as the three critical steps of User Stories. If there are any development teams looking for that magical balance between cycle and ceremony in their processes Card Conversation Confirmation is at the heart of the answer. Add into this Planning Poker and you've got all you need to implement a lean software development team - its a Software Development Lifecycle, in a nutshell. Hopefully this can be read as a journey of self discovery for the team and the individuals that make it up too.   more »

Agile teams should strive to ensure the daily stand up is firmly established as their focal practise - but that can be a challenge and while it is something else more amenable needs to take its place.   more »

Recently I went to a retrospective that was very well run with a simple change to approach. The team in question was in the habit of de-prioritising the retrospective. This probably came about because it was a rather dull affair - everyone sitting looking solemn at a projector screen while the project managers read out everyone's feedback and occasionally a subject would be raised that would lead to a 'hot topic' discussion.   more »

TDD (Test Driven Development) is a highly disciplined technique for producing high quality software, but it's possible to get benefit from its basic principles without following the practise to the Nth degree.   more »

The customer usually wants to see a plan as early as possible - it’s a reasonable request and its perfectly ok to do this providing the communication of the plan and its risks is carefully articulated and the pros and cons of the method are clearly understood by all. The key to mitigating the cons coming into play is to have a poker game with the senior management from both the customer and supplier.   more »

Satisfaction criteria certainly must be agreed between customer and supplier but should that agreement extend to the detail of test scenarios and scripts?   more »

Clients who want to be confident about a schedule to deliver an agreed set of functionality on time and within budget will benefit from the development team implementing standard deviation buffers...   more »

When a developer recieves a brief that isn't detailed enough its no surprise - we can't necessarily expect the business to fully understand how to articulate its requirements to a technical team. But when the business suddenly realises there's an important detail they didn't mention before just when the developer is proudly admiring his wonderful work on the last day of build - you can't deny him is startled expression. Especially as its communicated as "I have an urgent business critical change that must be delivered on the planned deployment date come what may."   more »

In Mike Cohn's book Agile Estimating and Planning there is a chapter entitled "Why Planning Fails" which cites estimates becoming commitments as one key reason for this...   more »