The Planning Game

The Planning game is where the team decides on what cards can be committed to for the next iteration.

Firstly, story cards will go through pre-planning. This is where a small group of the team discusses a selection of cards, making sure that they all have acceptance criteria and an estimate on them. Enough cards will go through pre-planning to give the team a choice in what they can commit to and cards will be prioritised by the product owner before they come into pre-planning but this order can be disputed by the team to an extent.

The planning game will happen at the start of an iteration. The team will sit round a table and the scrum master will stand to oversee what is going on and facilities the meeting. The story cards from pre-planning will be brought in and either put on a board or table, in priority order, so that everyone in the team can see them. I prefer them on a white board because then you can write estimates and notes next to the card as you are going.

Before the meeting starts, the scrum master lets the team know about any holidays people are taking in the next iteration, as well as what the last weeks velocity was. Velocity is the estimated time on the business value cards that were completed in the iteration. This is useful information for the developers to have, as it might effect their estimation of a card.

Each card is taken off the board and the product owner "sells the story" to the team, by explaining why the customer wants it done and what the business value is. Then it is passed to QA who read out each of the acceptance critera on the back of the card. The team discuss if the need anymore acceptance critera or changes made to the existing and once they are happy with the card the developers vote.

The vote lets the developers voice how long they think it will take for the card to be completed. Each developer will have voting cards (1/2 a day, 1 day, 2 days, 3 days, 5 days). The scrum master will ask them all to get their votes ready and then to reveal them. If people differ in opinion then developers will be asked to explain why they gave that vote before they vote again. When all developers come to a consensus, the estimate is written on the card.

When all cards have been formally estimated, the scrum master will total up all estimates on the business value cards and the team will decide who many of these cards they can complete, compared to previous velocities.


The cards for the iteration will be finalised and everyone in the team will commit to completing the card for the showcase to the business.

What makes up a team?

There is no hierarchy in an agile team. Everyone is part of decision that are made which affect the team. But what actually makes up a team...

Scrum Master - There role is to make sure that the team adheres to the values and practices of the agile methodology that they follow. The scrum master also makes sure that team does not over/under commit on work and looks after pay, budget etc for the team.

Product Owner - Goes between the business and the team. They prioritise the product backlog and make sure the rest of the team understand the goals of the work they are doing.

Developers - its all in the name really

QA - Quality Assurance. These guys test the software and make sure that the teams standards dont slip

Business Owners - The teams customers. They interact with the product owner to let them know what the would like the team to do next

Story Cards

Story cards are a high level requirement for the project. They should hold just enough information to spark conversations between the product owner, developers and the QA's.

In the team I currently work in, we have 5 different colours of story cards:

• WHITE - these are business value cards and each one should give the project some new functionality from a users point of view. They can also include re-factoring that the Product Owner has specified that the customer wants.
• YELLOW - these are non-functional cards and relate to things like the performance, availability etc.
• PINK - these a defect cards and are only raised if the white card that they erlate to is already "DONE". If the white card is still in play then it is not a defect, just functionality that hasn't been created yet.
• BLUE - these are technical debt or "Spikes" which are used to do further investigation on a topic before it is raised in a card.
• GREEN - these are cards for front-end designs.

There is certain information that needs to be on every card:

• It must have the card owner, which is the person that is currently in charge of this card coming into throughition
• The user story which is a quick sentence which describes what the card is about
• The acceptance criteria which are the things that need to be completed on this card for it to be "DONE". If possible, they should be written from a users perspective and they do not need to be overly prescriptive as this should make the QA and the Developers talk about the card
  
• The teams estimate on how long this card should take to develop
• The amount of work that has been done on the card each day and the amount of time they think they will need to complete it
• They should have some way of tracking they different people that have seen this card, e.g. developers, QA, Product Owners

The way that our team tracks the path of a card is by putting different coloured stickers for each type of team member:

• RED - Development
• BLUE - QA
• ORANGE - Product Owner
• YELLOW - Designer
• GREEN - "DONE"

Each week we collect all the business value (white) cards, which are "DONE", and present them to our customers in a showcase. This keeps them in touch with what we have completed and the progress we are making on the project. It also gives them the chance to see the product working and may decide that some of the functionality needs to be re-factored.

What Does Agile Mean?

What does "Agile" mean?...Everyone seems to have a different answer for this question. Agile is a group of methodologies which incorporates Scrum, XP, Lean etc. Some teams only implement one of these methodologies, where as others take principles from a mixture of methodologies.

Scrum
Scrum is an iterative, incremental process. It is use for projects which are required to be delivered quickly and also quick to change.

A Scrum project should include a prioritised product backlog of work to be done, so that the team can always see where the project is going and how it relates to what they are working on now. This backlog will be split up into sections and the first section will be brought into the iteration for the team to work on, (An iteration is the period of time that the team have to complete the work given and demo it to the business). The team will take part in a daily meeting, or scrum, where the progress the team has made is explained and they describe any upcoming work. The team also discuss any impediments they come across. A planning session will also be organised every iteration for all team members to agree what they want to bring in from the backlog. They will also all take part in a retrospective meeting where they reflect on the iteration just completed.

XP
XP stands for eXtreme Programming. It focuses on the principles of simplicity, communication, feedback and accountability. From these principles we will strive to decrease the time in which we respond to change and the time taken to deliver useful software.

XP has 12 practices:

•

The Planning Process - sometimes called the Planning Game, where the team decide what they can commit to in an iteration and estimate how long each story card will take them.

Small Releases - get the basis of the system in production early and then build extra features frequently
Metaphor - the team makes sure that they use common names across there work so that everyone understands descriptions and there are less faults in communication.
Simple Design - The team should meet the current requirements in the best way possible for that time and not worry about what may come in the future because that will be picked up in later iterations
Testing - XP teams focus on validation of the software at all times. Tests are written before code has begun so that we can check that the code meets the requirements before it even goes through quality assurance
Re-factoring - We need to keep the software clean: without duplication, with high communication, simple, yet complete. This makes sure that we can easily add in new functionality in further iterations
Pair Programming - XP programmers work in pairs to create the code for a story card. Each development machine should be set up with two monitors, keyboards and mice so that a pair can comfortably program together and so both are equally involved. This collaboration helps code flow quicker as you have someone else to bash around ideas with.
Collective Ownership - All the code belongs to all the programmers. This means the team can do changes without change requests.
Continuous Integration - Every time a pair has completed a slice of a card they will check their code into the build, therefore it happens multiple times per day. This makes sure no-one is working on old code and everyone is keeping up-to-date with what the other pairs are doing.
40-hour Week - If programmers work more that 40 hours a week they have a greater chance of make more mistakes.
On-site Customer - By having the customer on site, there is more communication and they have a greater control over what they want from the project. The team can also get answers to their questions quickly.
Coding Standard - All programmers need to write the code in the same way and make sure that it is to a high standard so that anyone looking at the code can understand what has been done.

Lean

Lean Software Development is a translation of lean manufacturing principles and practices to the software development domain.

The manufacturing principles are the production of goods using less of everything compared to mass production:

• •less waste,
• •less human effort,
• •less manufacturing space,
• •less investment in tools,
• •and less engineering time to develop a new product

The following characteristics make up Lean Software Development:

• •Eliminate waste
• •Amplify learning
• •Decide as late as possible
• •Deliver as fast as possible
• •Empower the team
• •Build integrity in •See the whole

	Scrum	XP	Lean
Planning Meeting	√	√
Small Releases	√	√	√
Simple Design		√	√
Best Practice	√	√	√
Test Driven Dev		√	√
Refactoring		√	√
Pair Programming		√
Collective Ownership	√	√	√
Continuous Integration		√	√
Professional Working Day		√
Onsite Customer	√	√
Product Backlog	√	√
Daily Meeting	√
Retrospective	√	√	√

*The information for this blog has come from a presentation by Raza Ahmad*

The Begining

Hi, I'm Nicole and I am a computer science graduate who has been in the working in IT for 1 year now.

Recently I have been moved to an Agile Web team to work on QA (Quality Assurance). I've decided to start a blog to record what I'm learning about this methodology and QA so that I can keep all my notes in one place and hopefully it will be a decent reference for others.

I will be writing about things I have learned in my team but won't be recording things in any particular order so sorry if this all seems a bit disjointed. The first blogs will be quite long and full of as much information as I can, so that those with no agile experience can understand the basics of how teams can work.

If you want to leave me comments on a post then they are very welcome and I will try and answer any questions as soon as I can.

Thanks,

Nicole