Quick Refresh: Agile Mehtodology

 Principles behind the Agile Manifesto  We follow these principles:

1.       Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

 

2.       Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

 

3.       Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

 

4.       Business people and developers must work together daily throughout the project.

 

5.       Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

 

6.       The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

 

7.       Working software is the primary measure of progress.

 

8.       Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

 

9.       Continuous attention to technical excellence and good design enhances agility.

 

10.   Simplicity--the art of maximizing the amount of work not done--is essential.

 

11.   The best architectures, requirements, and designs emerge from self-organizing teams.

 

12.   At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 

Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 

That is, while there is value in the items on  the right, we value the items on the left more

What is Agile?

Agile software development refers to a group of software development methods. 

·          

·         It promotes development through iterations, open collaboration and process adaptability throughout the life cycle of the project.

·         It chooses to do things in small increments, with just-in-time planning of strictly time-boxed work episodes rather than up-front master plans

·         It encourages stakeholder involvement throughout the life of the project

·          

·         Its values are born out of the Agile Manifesto and enshrined in the 12 Principles of Agile Development.

What is Scrum?

Scrum is a framework for developing complex products or systems.  It comprises a set of roles, artifacts and time boxed events.

 

 

 

Scrum Teams 

Each Scrum team will consist of a Product Owner, a Scrum Master and development team members. 

Product Owner

The Product Owner is the project’s key stakeholder. The Product Owner is responsible for the Product Backlog and is the interface between the Scrum Team and the stakeholders.

They are responsible for: 

·          

• Determining the priority of stories and ensuring that enough information is known about the highest priority items before each sprint.
• Continually ‘grooming’ the backlog in order to ensure that the story list and priority order is up to date
• Determining acceptance criteria
• Confirming deliverables meet requirements

The Product Owner may be someone from inside or outside the team.  

Scrum Master

The Scrum Master is responsible for ensuring that the Scrum framework is followed.  They are a facilitator rather than a team leader.

He or she should try to keep the team focused on their tasks by removing impediments and minimizing distractions.  The Scrum Master should therefore take responsibility for setting up meetings, ensuring tasks are updated, recording stories in Jira, and ensuring any issues that arise are resolved.

As the Product Owner reports to the business, the Scrum Master provides a counter balance to the Product Owner role by pushing back on requests from the business which may undermine Scrum methods.

Development team

The development team will consist of the other members of the team that have been assigned to the project.

Whilst each team member will have a primary skill (BA, programmer, tester etc), cross functionality is encouraged so team members should be prepared to pick up any tasks required in order to complete a story which is within their ability.

The team is self-organizing in that they make their own decisions and select which work to do themselves.  Neither the Product Owner nor the Scrum Master assigns tasks to the team members. 

Artifacts

Product Backlog

The Product Backlog is a prioritized list of requirements, or User Stories.  The Product Owner has sole responsibility for the Product Backlog and therefore no stories can be added without his or her approval.

Sprint Goal

The Sprint Goal represents all of the stories that the Scrum team have committed to delivering in the sprint.  The Scrum Master will create a JIRA issue to represent each story and assign it to the sprint using the Fix Version field.  Your Sprint Goal is therefore all JIRA standard issue type assigned to that sprint.

Sprint Backlog

The Sprint Backlog represents all of the tasks required to implement the stories in the Sprint Goal.  A JIRA sub-task is created for each task against the relevant user story.

Increment

An Increment is the sum of all product backlog items that have been completed since the last software release. While it is up to the Product Owner to decide on when an increment is released, it is the team’s responsibility to make sure everything that is included in an increment is ready to be released. This is also referred to as the Potentially Shippable Increment (PSI).

 

Sprints

Each project will be divided into sprints of equal length.  New projects will also be preceded by a sprint zero.

Sprint Zero

This refers to the time that is required before the first sprint to ensure that enough is known about the project for development to start.  It should include:

·         High level architecture design

·         Agreeing roles

·         Gathering user stories and entering them into the Product Backlog

·         Determining the items with the highest priority and ensuring that enough information is known about the requirements.

·         Allocating development and test environments

·         Outlining the scope and goals of the project to all those involved

·         Initial sizing of stories

This is not time boxed.

Sprint length

Once sprint zero has been completed the project sprints can begin.  The sprint length needs to be long enough to be able to produce items of functional value but be short enough to provide enough chances to review, reflect and re-plan throughout the delivery of the project.

Our standard sprint length is either two or three weeks, however for certain projects it may be necessary to make them larger.  If you think this is the case then discuss with your Scrum Master and Development Manager.  Sprints must never be longer than one month. 

 

 Events

(1) Planning Meetings

The planning meetings are held on the first day of the sprint.  No more than 5% of the sprint should be allocated to the them; for a two week sprint this is 4 hours. 

Planning meeting Part 1

The aim of the first planning meeting is to define the Sprint Goal.   The meeting should be attended by the whole Scrum team. 

The team should select the highest priority items from the Product Backlog and discuss each one in turn.  It may be necessary to invite people outside of the team to attend the meeting if the Product Owner does not have enough information about the requirements to answer the developers’ questions.

Once the team are happy they understand the requirement and have an idea of how to implement it they should assign it a number of story points.  In order to do this they should play rounds of planning poker until an agreement is reached.

Once stories are sized the team can decide how many they can complete in the next sprint based on their previous velocity.

Planning meeting Part 2

The aim of the second planning meeting is to define the Sprint Backlog.   The meeting should be attended by at least the Scrum Master and Development Team.  The Product Owner may or may not be needed, it is up to the team to decide.

Before the meeting starts the Scrum Master should have created an issue in Jira to represent each story, added the mandatory QA tasks and assigned it to the sprint.

During the meeting each story should be discussed to determine what tasks will need to be carried out in order to complete it.  The Scrum Master should create these as sub-tasks on the main story.

Once all tasks have been entered they should be assigned an ‘ideal hours’ value.  Again, this is a relative sizing and not intended to be used to track developer’s progress hour by hour.  It is only used in order to produce a burndown chart which gives the team an idea of how their sprint is progressing.  It is not expected that the total number of hours assigned to the sprint would add up to the total number of man hours available.

Teams may find it easier to hold this meeting on the phone so that everyone can view the Task Board whilst the Scrum Master enters the tasks. 

(2) Daily Scrum meetings

The Scrum meeting is held every day and is attended by the development team and the scrum master.  It is time boxed to 15 minutes and this should be strictly enforced by the Scrum Master.

Each team member should answer the following questions: 

·          

• What did you do yesterday?
• What will you do today?
• What issues are preventing/could prevent you from achieving the above?

The daily scrum exists to surface issues, not resolve them.  If issues arise the Scrum Master is responsible for ensuring that the relevant follow up discussions are held with the right people in order to resolve them.  Developers should update the progress on their tasks before the meeting.  

(3) Sprint Review

 At the end of each sprint a sprint review meeting is held.  This should be attended by the whole Scrum team and the project stakeholders.

The purpose of the meeting is to present project progress and to demonstrate completed functionality. Only stories that are ‘done’can be included.

Ideally we want review meetings to be attended by the business stakeholders, however it may take time to get user fully engaged in the process.  If your users are not fully engaged, or if your project is IT related then you should identify a stakeholder within the team that you can demo to, for instance a Development Manager.

The Sprint Review meeting is time boxed to two hours for a two week sprint. 

(4) Sprint Retrospective

After the sprint review a retrospective meeting is held.  This is attended by the whole team and is a chance to reflect and correct processes. 

Team members should answer the following questions:

·          

• What went well during the last sprint?
• What could be improved during the next sprint?

The Scrum Master should ensure that the opinions of all members of the team are heard.  Actionable items should be recorded in the Product Backlog. 

(5) Project Retrospective

On completion of a project another retrospective should be held whose format is similar to the sprint retrospective but at project level. 

After the meeting is held the Scrum Master should send out an email to the wider application team summarizing the main points so that lessons learnt are shared with the whole team.

 

 User Stories

These are requirements, phrased in a way that captures the 'who', 'what' and 'why' in a simple, concise way. 

As a _____

I want to ______

So that _____

The story should also include a list of acceptance criteria which will explain what tests conditions the story needs to pass in order to be classed as 'Done Done'.

Story Points

Story points are a way of measuring the relative sizes of stories. 

The first time stories are sized, the smallest one should be selected and allocated one story point.  Every other story should be sized in relation to that story based on size and complexity, but only a certain amounts of points are allowed to be allocated.  Our standard is to use a modified version of the Fibonacci Sequence:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100     

The reason for using the Fibonacci Sequence is to reflect the inherent uncertainty in estimating larger items.  If your estimate is larger than 8 then it's probably an indication that you should break the story down into separate stories.  

It is important that story point sizing is consistent throughout the whole project so it can be used for calculating velocity. 

Planning Poker

Story points should be allocated using planning poker. 

Each member of the team has a set of cards with the above number of points on them.  Once the team has finished discussing a story, each member selects the card with the number of story points that represents how big they think the story is.  Everyone puts down their cards at the same time and if there is any difference then team members discuss the reasons behind their choices and another round is played.  If a few rounds have been played and the estimates are still different, yet close, chose the larger of them. 

In London we have two decks of poker cards but it can also be played online, however, please make sure you don't enter any data that identifies the company or any sensitive information.  

Velocity 

The team's velocity is the number of story points that they complete in sprint.  This is a valuable statistic as once you have completed a sprint it allows you to more accurately decide how much work can be completed in a sprint.  For instance, if your velocity is 10 then in your planning meeting you know that you should allocate stories that add up to roughly that amount. 

For the first sprint the velocity must be guessed and you may find that your velocity is lower at the beginning of a project whilst team members get up to speed.  After a few sprints however it should level off.

Tracking progress

Burndown charts are used to track progress both within a sprint and across sprints.  The sprint burndown uses the 'ideal hours' estimates assigned in the planning meeting and gives you a rough idea of whether you are on track to complete all stories within your sprint.  If at midway through the sprint you are far above the guideline the team should consider whether the story with the lowest priority should be dropped and the team concentrate on getting the remaining stories completed.  It is important to remember that there is more value in delivering three completed bits of functionality rather than two completed and two half done.

A project burndown is created by totalling the number of story points for everything in the product backlog and plotting that against the number of sprints.  This can give you an indication of how many sprints you will need in order to complete all of the items in the backlog.

Documentation

The JIRA issue should be thought of as the documentation for the story - Lifecycle Documents are not necessary as the team will have already have collaborated in the analysis by agreeing how the story should be implemented in the planning meetings.  However, the JIRA description needs to contain enough information to bridge the gap between the requirement (the title) and the tasks and code changes.  This is extremely important as it provides information to QA reviewers, Auditors and anyone who may need to look back at the change after implementation.

As a minimum the following sections are required:

Requirement

A paragraph or so expanding on the title

Code changes

A summary of why you are changing the code you have amended.  This should be at a high level and should not contain actual code snippets.  You should also document the reasons behind any decisions that you had to make.

Test Summary

Level of testing required and list of conditions

Documentation

List of confluence pages created/updated as part of this change.

 

If the story is complex then analysis can be written up in a lightweight document and attached to the story.  If you are working on a regulatory project, check if the regulator requires access to technical documentation.  If so then a much more detailed, formal document will need to be produced.