Estimation

Extreme Programming was created by Kent Beck one of the original group that formed the Agile Manifesto. He worked on an Agile concept to develop fast paced framework to create high-quality software that was based on engineering disciplines for Chrysler payroll project. Its focus on fast feedback and customer centric approach makes it suitable for ever changing businesses with a view to have a quick turnaround and improve productivity. The term 'Extreme' is to imply taking disciplines to the extreme.

XP is thought to be best suited to high-risk projects where the requirements or demands are likely to be unstable, and push the XP mindset towards success and delivery. What makes XP more intriguing is that many Agile frameworks are adopting some of its practices to improve the quality of the deliverables, practices like Pair programming and Continous Delivery.

The objective for Extreme Programming was to evolve displines created by developers for developers. XP is broken in to 3 main parts, Values, Principles and Practices.

The mindset for an XP developer is slightly different from that of a scrum developer. XP can work in chaos and stabilise and improve the quality of the product, this mindset is set very early on and the values sit on top of this thinking. There are 6 simple values:

Typically there are four main roles in XP - Customer, the developer, Coach and the Manager or Tracker. There are a maximum number of upto 12 members in a team.

1. Xp Customer

The Customer works within the XP team as an requirements provider on behalf of the business. The idea behind the customer is to get the developers working very close to the requirements and if they raise any questions or issues they will be able liaise closely and effectively to the Customer and vice versa.

2. Xp Developer

The developer will take requirements from the Customer and turn these requirement or user-stories into deliverables such as function or a feature, this would be estimated by the developer and tested separately by the developer.

3. Xp Coach

The XP coach is a servant leader who is empowered to support the team on their XP practices. To ensure they can harness the core values and practices of XP and allow teams to build knowledge and reflection on the quality of the work. They are not leaders or facilitators, they are there as a guide to provide their agile experience to the wider team.

The XP coach can run workshops to optimise the teams techniques using observations, the learnings are then made to the wider team. They can also be used to provide support and encouragement to the XP team when work demands are high or challenges are occuring.

They have a key pivotal role in the agility of XP in team.

4. Xp Manager (Tracker)

The Xp manager main roles revolve around the release planning and iteration planning meetings for the Xp team. They will be responsible and accountable that the whole team understand the planning game as well as ensure there is transparency in the process. The Manager will ensure the team is committed to the delivery and the team is on track with the milestones.

The manager is also responsible to ensure that estimation and prioritisation of the user stories are occuring, and will work closely with both the Customer and the developers to ensure the accuracy of those estimations based on the relevant experience of previous iterations.

They will also have tracker duties to be able to monitor and track progress of the team in terms of deliverables and quality of product, these metrics will be collated quantitively from the team.

The objective for this is to improve the quality and collaboration of the team members, particularly helping to assist to standards and techniques. There is also reduced amount of skill dependency so if someone is away there is always a standby.

This is a meeting ceremony that occurs once in a iteration or sprint, it is similar to the Sprint Planning meeting in a scrum. The meeting focuses on two planning activities Release Planning and Iteration Planning

Here the customer goes through the features that are to be developed into the future iterations, a very high level estimate is given around the feature items, the objectives and deliverable are recorded on a feature board and the increment plan is updated to record the timescales. During the estimation the development team analyse the requirements determining the work and complexity required for each as well as any risks or impediments. Once the estimations are completed the feature is added to the product plan or roadmap.

This meeting plans the activities to be carried out in the upcoming sprint - this is a development team task (without Customer). Customer prioritises the features that will be developed during the Iteration and the development team will do a deep dive estimation on the features and these is then placed into the Iteration plan. The developers will then create all activities and tasks associated to the features and these are then committed to the Sprint.

Test-First Development or Test-driven Development is a concept which is different to unit test, In Unit testing feature logic is added and the functionality would then be developed finally the tests would begin. In Test Driven Development the Test is created before the coding logic is started.