Planning poker

This fortnight’s discussion at the London Agile discussion group was all about planning poker. What is planning poker and who should be included in the process? Should the Product Owner, ScrumMaster, analyst take part in sizing? Do you size development and testing separately?

The session started with a brief description on what planning poker is and when you use it.

Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators. 

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Then people stated what topics they wanted to cover which was captured and grouped using post it notes. These suggestions included:

  • When should it be used? Alternative methods

This was quite interesting as for me I would only use planning poker in an estimation session, getting enough stories for the next sprint. Not all the stories in the backlog will be delivered so why would you spend time sizing them. To follow the just in time theory, make sure you have enough stories sized and agreed on that will keep the team busy for the sprint. Potentially if the velocity increases have some stories that have been analysed and have the acceptance criteria ready ready so another sizing session can be run during the sprint.

From experience if you size too many stories that are not developed in the sprint, when the developers come to doing them a few weeks later the memory needs to be refreshed exactly what was involved, so if you try and do too much upfront this adds delays later on in the process.

Alternative methods included sizing by functional tasks, though I feel this will take more time and this is meant to be an estimation that you don’t spend too long or too much energy on. It’s a way to create enough work for the iteration. Some teams don’t estimate using planning poker but use BDD in the planning session, writing their tests and from this work out how many stories they can do.

  • Who should be involved?

Interesting to see what people do! The consensus was to have the whole team there, as in agile teams this is normally less than 10 people. This session is useful to have the team in as the Product Owner of the Business Analyst presents the story and is there to answer any questions so everyone hears the same information.

Some teams just have the team delivering sizing and others included the PO, but when they average out the numbers the non-delivery peoples’ numbers are not included. The advantage of getting the PO to size is that is they size low and the developers/testers size high it can highlight a difference in understanding of the exact capability the PO needs.

It is useful to have people in there that have testing knowledge as sometimes a change that is very simple can have a massive impact on the existing system so a lot of regression testing will need to be done.

There is no ‘correct’ solution but try different things and see what works for your team.

  • When do you send a user story back – what is too big?

The majority said that if it were 8 points or higher they would push the story back to the PO to split it further as higher than 8 brings in more uncertainty of exactly what is needed so if it can be split people will get a better understanding. Though it was highlighted to remember INVEST and that the stories need to be independent when they are split into smaller pieces.

  • Resizing? When do you lock a story down?

When a story enters the sprint the size is locked down. During planning poker you may want to resize after the people with the highest and lowest scores have explained why they have voted this way.

  • For the Release plan do you size the whole backlog?

It was highlighted that managers like knowing how long things will take. For the backlog majority of places size this using T-shirt sizes to give a basic estimation of time. In Agile you are always learning and adapting to needs so what is in your backlog and what is delivered is rarely the same so sizing a project using requirements is hard. A project could be time boxed, delivering the prioritised items first and then see where it is at the end of the time box.

There was a good selection of different experiences with the people involved in the room which allowed a good discussion. To me there is no book way to do these things, each team is different and you need to be flexible to allow for this.

How to be an Agile Coach

It was a London Agile Discussion titled “So you want to be an agile coach? Well, what is it and how do you become one?”

We split into 3 teams and the first exercise we did was to write on post notes everything we thought an Agile Coach did and the characteristics they would need to perform this role. Then we reviewed the things we had written down and had to put C (coach), S (scrum master) or both on each post it note if we thought this was a role that the Scrum Master may also do. Do both these roles do a similar thing and need the same characteristics to do well? Is an Agile Coach just doing the Scrum Master role but just on a bigger level?

IMG_0058From this we were given categories to sort the cards into which were meant to be the different types of Agile Coaches, including guide, cheerleader, guardian of quality and performance, servant, shepherd, bull-dozer or others. These choices came from the book by Lyssa Adkins. This caused a few interesting conversations depending on how the person imagined each category type to be like.
IMG_0061Then all teams came together to present what they had done, making one main post it note sorting result. If the individual groups had differences with where certain post its should go this was now amplified but discussed to a consensus.
IMG_0063It was a very interesting meetup as for me I feel there are a lot of Agile Coaches but maybe doing slightly different roles. It got me wondering would it be better if someone was a coach first and then moved into agile? Is the real need coaching or is it more counselling? 

Very interesting discussions and a good night.

How to split user stories – London Agile Discussion Group

The London Agile Discussion Group were talking about How to Split User stories which is a topic of great interest as it is hard to do this quickly but well and it is always great to hear how other people deal with similar experiences.

You start a project and depending what side of the fence you sit on depends which issues/experiences you may have. For me in the Business Analyst role on a new project you need to ensure that there is a clear vision for the team to work towards. Then you start working on the requirements with your Product Owner/Customer. This is where it can get interesting as even what seems like the most basic requirement actually probably isn’t. A request for a login page seems quite innocent but if that if the only acceptance criteria is that Job Blogs can login and that is what is delivered I’m pretty sure most customers will say that is not what I wanted. There are different levels of requirements, bronze, silver and gold. What is needed now and how much time do they want spent on this requirement. Do they need registration as well, do details have to be collected, does it need to link to LDAP? Even a story that seems basic need to be split a little more.

Why do you split stories? We came up with a few reasons but there are a lot more:

  • Promote discussion and understanding
  • Several people can work on it
  • Reduce time to deliver and get feedback
  • Fail fast
  • Fit into an iteration
  • Improve acceptance criteria
  • Get better requirements

There are different ways to slice up a story, vertical or horizontal.  Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”

slicingA horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture and this isn’t the wrong way of thinking about its as most things are built this way. If you were to build a house, you would slice up the project horizontally. First you would pour the foundation,  then put up the walls. Finally the roof goes on and many more steps, leaving the finishing work for last. This same thinking usually gets applied to breaking up backlogs in Agile development. It would seem silly to build a house where you finished one room completely at a time.

There is a distinct difference though, between developing software in an Agile way and building a house. In Agile software development you don’t know exactly what you are going to build until you are done building it. With a house I hope this isn’t the case! You start with some blueprints that you have drawn up ahead of time.  You know exactly where each wall will be and where each outlet will be.  You may have even built houses before that are very similar. When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.

To be Agile means responding to change. Building a house, you do not expect the customer to say “hmm, yeah, I don’t really like that wall there” or “actually, I am thinking we are going to need 5 bedrooms now.” In developing software when the customer can see how it is turning out, requirements may start to change and new ideas appear.
slicing hVertical slicing is basically building one room at a time. It is not functional as a house straight away, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost. The point in building our software “one room at a time,” is to give the customer a chance to see the product as it is being built and this enables them to test it out. They can’t live there until it is all done.  But, they will have the ability to step into a room and envision it with all their furniture in there.

Customers don’t care about foundations and framed in walls.  As a developer, you may be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse how can they test it? Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.

The idea is that instead of breaking a backlog up into the following:

  • Implement database layer for A, B and C
  • Implement business logic layer for A, B and C
  • Implement user interface for A, B and C

The backlog is broken up into something like:

  • Implement A from end to end
  • Implement B from end to end
  • Implement C from end to end

Developers think about the horizontal slicing when planning out the implementation of a backlog, wanting to implement things by building one layer at a time. Thinking about how to break apart a backlog into vertical slices requires a step outside the understanding of the code and implementation, instead thinking about the backlog in small pieces of working functionality. There is always some progression of functionality that can be found in a large backlog. Meaning there are always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development. Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste. Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices. It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that were not planned for.

Vertical slicing is about delivering working functionality as soon as possible, delivering working functionality as soon as possible is important and valuable.

There is a good flow chart on how to spilt stories how to Split a User Story that helps you break it into smaller sections and obviously mentioning INVEST that we reviewed in the meeting. Stories should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

ecWe then split into small groups to run through an exercise on Elephant Carpaccio. You ideally need 2 hours to run this and you need developers for this. We decided to do it without the coding and show and tell. You need to make a calculator, what are your stories for this, how do you split up the project and how do you ensure you get value sooner. I think this exercise was an eye opener and I’d like to run it again as it makes you think, trying to work out the priorities and what would be most useful. I also think it was good as it tried to make you split up the stories as small as possible but each story had to add extra value and could be demoed. I’d recommend this to teams to help developers see the different on how you could split stories. It was a very interesting session.