Skip to content
SM Tutorials & Certification


Business systems do not always end up the way that we first plan them. Requirements can change to accommodate a new strategy, a new target or a new competitor. In these circumstances, conventional business management methods often struggle and a different approach is required.

Agile business management is a series of concepts and processes for the day-to-day management of an organization. As an Agile manager, you need to understand, embody and encourage these concepts. By embracing and shaping change within your organization you can take advantage of new opportunities and outperform your competition.

Using a combination of first-hand research and in-depth case studies, Directing the Agile Organisation offers a fresh approach to business management, applying Agile processes pioneered In the IT and manufacturing industries.


‘On two occasions I have been asked, “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.’ Charles Babbage, 1864


The “Agile Software Development Manifesto” was developed in February 2001, by representatives from many of the fledgling “agile” processes such as Scrum, DSDM, and XP. The manifesto is a set of 4 values and 12 principles that describe “What is meant by Agile”.

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan THE AGILE 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 time-scale.
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 maximising 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.


The term Agile actually refers to a concept, not a specific methodology. There are many, and sometimes conflicting, methods that can be used under the Agile umbrella. these include;

  •  Agile Unified Process,
  •  Behaviour Driven Development (BDD),
  •  Crystal Clear,
  •  Dynamic Systems Development Method (DSDM),
  •  Extreme Programming (XP)
  •  Feature Driven Development (FDD),
  •  Kanban
  •  Lean Development,
  •  Rapid Application Development (RAD),
  •  IBM – Rational Unified Process (RUP),
  •  Scrum,
  •  Test Driven Development (TDD),



All of the above methods have four key points in common.

1. Iterative design process
2. Continuous stakeholder engagement
3. Aims for quality and reliable software
4. Short development cycles (up to a month) allows to a regular delivery of software.

This shows that an Agile approach is appropriate in contexts where the outcomes are not known (or can’t be known) in advance and where the delivery of the outcomes cannot be fully controlled.

The following figures1 is an excellent example of the differences between traditional (or phased) software development vs. the Agile approach of iterative development.


The techniques and frameworks within Agile aim to increase development efficiency, by eliminating all ‘wasteful’ processes. Drawing on the successful concepts from the Lean manufacturing frameworks, we can define 3 major forms of waste.

  • Mura (Unevenness): Mura exists where there is a variation in a workflow, leading to unbalanced situations, most commonly where workflow steps are inconsistent, unbalanced, or without standard procedures.

1 Images with thanks from Jeff Patton:

  • Muri (Overburden): Muri exists where management expects unreasonable effort from personnel, material or equipment, most commonly resulting from unrealistic expectations and poor planning.

  • Muda (Waste): Muda is any step in the production workflow that does not add direct value to the Customer. The original seven wastes, as defined by the Toyota Production System (TPS), were:
    1. Transport,
    2. Inventory,
    3. Motion (moving more than is required),
    4. Waiting,
    5. Overproduction,
    6. Over Processing (from poor design), and
    7. Defects (the effort involved in inspecting for, and fixing, defects).



The successful application of an agile methodology depends on the relative maturity of an organization in relation to Customer Engagement, Staff Resources, Technology, and Processes. These measures are defined as follows:

  • Customer Engagement – Product owners involved in teams daily activities, define requirements, drives the prioritization of requirements and has decision-making delegation of authority.

  • Staff – have experience in an agile method, are skilled in the Standard Operating Environment (SOE) toolsets, have an understanding of the underlying data and technical infrastructure, and are conversant in the development, testing, and configuration and release procedures.

  • Technology – a stable and well-documented technology stack, with clearly defined ownership and service levels, providing discreet development, testing and release environments that are sized and supported for the delivery of projects, and controlled through rigorous configuration and release management.

  • Processes-business processes exist for all domains, with cross stream interdependencies defined and service levels agreed, and clear business ownership and delegations of authority identified.



Being a generic term, Agile means different things to different people. Therefore, before we go much further, I should clarify some of the more common misconceptions surrounding Agile.

  • Agile is ad hoc, with no process control: First of all, Agile isn’t a lack of process. Agile provides a range of formal processes, and methods, to inform work processes, customer engagement and management models. Conversely, Agile isn’t about blindly following the prescribed ‘agile’ methods and processes. Agile is about using your common sense to apply processes, as determined by the current situation, and shaped by the agile philosophy.


  • Agile is faster and/or cheaper: Agile isn’t significantly faster, or cheaper than alternative frameworks. Put another way, in most cases, you can’t get significantly more effort out of your Teams by moving to an agile approach. While there is an overall efficiency gain when utilizing agile methods, well-managed Agile and nonAgile Teams will deliver products and services in approximately the same time and effort.

  • Agile teams do not plan their work or write documentation: Agile is not an excuse to avoid appropriate planning or writing documentation. It is an on-demand, or Just-In-Time, approach that encourages continuous planning and documentation, but only when needed for specific Customer Requirements. This allows Customers and Teams to determine if the planning, or document, adds value to the process or product. It creates an opportunity to emphasize valuable documents and eliminate anything that isn’t useful.

  • An Agile project never ends: While this may be true in some situations, the benefit of Agile is that work will continue while the Customer continues to gain business value, and that value is worth more than the cost of developing it. Most projects, in any industry, have a point of diminishing returns. This is the ideal time for an agile project to end.

  • Agile only works for small organizations: Agile works for projects, teams, and organizations of any size, not just small projects. That is not to say that it will work for all organizations, but the size is rarely a factor. Large and complex projects and organizations are often excellent candidates for Agile transformation, where it is difficult, or impossible, to know all your Customer’s Requirements in advance.

  • Without upfront planning, Agile is wasteful: This assumes that your Customer knows the detail of all of their Requirements in advance. If this is true, then, by all means, undertake comprehensive upfront planning. However, in reality, this is rare and usually leads to the greater ‘waste’ of having undertaken design and development work that was ultimately unnecessary. Agile Business Management encourages minimal upfront planning, ensuring everyone is working towards a thesame goal and reduces the risk of miscommunication.

  • Finally, Agile is not the solution to all your problems. It is a change in approach and culture that comes with its own set of benefits and issues.


Scrum is described as a ‘framework within which you can employ various processes and techniques’, rather than a process, or a technique, for building products. The Scrum framework is primarily team-based and defines associated roles, events, artifacts, and rules. The three primary roles within the Scrum framework are:

1. The product owner who represents the stakeholders,
2. The scrum master who manages the team and the Scrum process
3. The team, about 7 people, who develop the software.

Each project is delivered in a highly flexible and iterative manner where at the end of every misprint of work there is a tangible deliverable to the business. This can be seen in the following diagram.

The requirements that form the basis of the project are collated into what is called a Project Backlog and is updated regularly. The features that are associated with these
requirements are termed User Stories. This relationship is illustrated in the following diagram:

The work is time-boxed into a series of 1 to 4-week cycles where the business and project team estimate which User Stories in descending priority order are achievable each cycle, or Iteration. This subset of User Stories from the Project Backlog form the basis of the Iteration Backlog planned for delivery over that two week period.

Under Scrum, there are 3 timeboxed (or fixed duration) meetings held during an Iteration plus a daily stand-up meeting for the team, scrum master and (ideally) the product owner. At the beginning of a sprint, features to be developed during the sprint are decided during the sprint planning meeting. At the end of the Iteration are another 2 meetings, the Iteration review, and Iteration retrospective where the team reviews the product and demonstrates the use of the software, as well as reflect on, and improve, the Iteration process itself.

After the sprint is complete, the next set of User Stories is selected from the Project Backlog and the process begins again. Burn rate is monitored to determine when funding will be exhausted.


‘So Mr. Edison, how did it feel to fail 10,000 times?’ ‘Young man, I didn’t fail, I found 9,999 ways that didn’t work’
Thomas Edison, anecdotal (on his invention of the incandescent light)


The project team is a self-governing group capable of independently delivering to a customer’s requirements. As a result, the team requires cross functional representation of skills and knowledge in the data, tools and infrastructure domains.

A typical project team can be comprised of the following:

  •  Product Owner
  •  Scrum Master
  • Architects / Analysts
  •  Designers
  •  Developers

The project team characteristics and responsibilities are as follows:

  • 7 ± 2 (5 to 9) resources who are allocated full-time to a Sprint
  • Cross-functional in nature across skills, applications, data and organizational
  •  Self-empowered
  •  Responsible for delivering the product
  •  Determine the tasks required to deliver each feature
  •  Estimate the effort for each task
  •  Develop the features
  •  Resolve issues

Ideally, the project team, including the product owner are co-located.


Interesting roles are individuals who have an “interest” in software development. Whilst they should be kept informed of progress, they do not have the same level of responsibility and input into the development as committed roles. Interested parties include the Users, the Customers, and the Product Owner.

Committed roles are responsible for software development, and are the people who “do” the work. Committed parties include the Scrum Master, the Team and Testers.


aka Feasibility
aka Project Initiation
aka Sprint 0 (XP)

‘It is always wise to look ahead, but difficult to look further than you can see.’
Winston Churchill, ~1960

Project Initiation



Contrary to common opinion, it is very important to have a good specification before
starting an agile project. By building this specification (or backlog in agile terminology) a project will;

  •  Reduce Risk & Uncertainty
  •  Improve Decision Making and integrate With Long term Goals
  •  Improved cost planning (including Staff Hiring)
  • Prioritize research and information Gathering


Unlike traditional waterfall methods, the specification phase of an agile project is very short; usually, no more than 1 or 2 days and the full team should be available at inception. During the period the customer should be made fully aware of their role. The design should contain the following;

  • Problem statement that needs to be addressed
  •  Desired business objectives, outcomes, and benefits for this project
  •  Identified key stakeholders
  • High Level Business Requirements
  • Architectural and technical scope
  • Testing requirements


The outcomes from Project Initiation, or Sprint 0, are:

  • The team should be identified and brought together
  • If not part of the team, identify and train the product owner
  • Create the product backlog in low detail. Allow customers to slowly build the
    product requirements throughout the process.
  • Estimate the product backlog.
  •  Plan length of the sprint, anywhere from 1 day to 4 weeks. Each sprint should
    accomplish something releasable. Short sprints short can reduce overtime.
  • Add any team training to the backlog as tasks.


The backlog contains all the User Stories (features) for the product. The Product Owner is responsible for defining the User Stories and assigning each with a priority for delivery. The order may also be influenced by Story dependencies or business value e.g. a lower priority Story may need to be done first before a higher priority Story can be started.

The User Stories describe the set of features that will satisfy each Information requirement. The high priority User Stories that are candidates for the next Sprint require sufficient detail for the team to a solution, and should be sized to fit within two weeks.

Each User Story should meet the INVEST characteristics, as defined by Bill Wake.

  •  Independent: Each Requirement should be as self-contained as possible, with
    minimal dependencies on any other Requirement. This allows for easy reordering or removal, as Customer Requirement’s change.
  • Negotiable: The Customer can change a Requirement at any time, up to the point it enters the Sprint Backlog (see Chapter 4: Work, the Agile Way).
  • Valuable: Each Requirement should deliver a tangible, and measurable, benefit to the Customer.
  • Estimatable: The definition of each Requirement is such that the Team can estimate it.
  • Small: The estimate, and delivery, of a Requirement, should be within a few days, or a single Sprint.
  • Testable: Each Requirement should have appropriate quality control and quality assurance metrics, so the Customer can validate their Deliverables against the original Requirement.

Each feature should contain, at a minimum, the function, priority, an estimate of the effort to develop and the estimated risk (0 – 100%) based on how accurate the team feels the estimate is.

In can be helpful to structure each User Story in the following format.

As a [role]
I want a [goal/desire]
So that [benefit]

The [role] is the expected end-user of the User Story, who is usually different from the Customer. The [goal/desire] of each User Story describes what should be delivered, and the [benefit] provides the context or the Why.


It is important to note that to increase the accuracy of any estimate, the effort involved increases exponentially. In Agile, we are only interested in the initial estimation.

By keeping Sprints short, we can better review and respond to deviations in the estimate quickly. See the Burndown chart chapter for more information.


A Story Point is a single number intended to represent all of the work required for the whole team to build the final product. As a result, to perform estimation based on Story Points it requires cross-functional representation of all the requisite skills and knowledge in the Business Intelligence Platform data, tools and infrastructure during the Sprint Planning meeting.

Story Points are used for the high-level estimation of User Stories. They are usually based on the delivery of similar User Stories in previous Sprints. This assumes that the project team, data, and infrastructure are relatively constant between one project and the next. The size of a Story Point for a given project team will eventually normalize over time.

All Stories should be assigned an estimated effort, or cost, to implement. We use a modified Fibonacci series, such as 1, 2, 3, 5, 8, 13, 20, 40, and 100, to represent effort. This encourages features to be split into the smallest task possible and provides a more realistic estimate range.

Task estimation is performed at the Sprint level. During the Sprint Planning session, the team breaks the User Stories into their composite tasks to determine how they will be delivered. The process of solution decomposition may reveal additional tasks, or more complex tasks that were not apparent during the high-level Story Point based estimation that impact what was planned to be delivered. The scope of the Sprint can be renegotiated with the product owner if this is the case. Unlike Story Points, these estimates are an indicative idea of how much time they will take in an ideal world.


Tasks can be estimated in 4 ways.

1. Expert opinion: The team member with specific understanding, or who is most likely to develop the task, can provide a more accurate estimate of effort.

E.g. A database administrator can better estimate effort for database tasks.

2. Comparison: Comparing a task to another, already estimated, task. e.g. “Task A is about twice the effort of Task B”

3. Components: If a task is too large to accurately estimate, break it into small subtasks. e.g. User management can be broken into interface, login, ACL, etc.

4. Planning poker: If using Planning Poker, estimates must not be mentioned at all during a discussion to avoid anchoring. A timer may be used to ensure that discussion is structured; any person may turn over the timer and when it runs out all discussion must cease and a round of poker is played.

Each person lays a card face down representing their estimate of the task, and then simultaneously turns their cards over.

People with high estimates and low estimates are given an opportunity to discuss their estimate before anyone else can speak.

Repeat the estimation process until a consensus is reached.


Converting an estimated cost into estimated time is very simple. There are 2 primary
modifiers that we use. Staff overhead and estimate accuracy (or risk).


This is a percentage modifier for staff available to work on specific project tasks. It allows you to take into account factors such as estimated leave, illness, breaks, scrum meetings, etc. The industry standard modifier is 25%-40%, though you should modify this as required. To calculate staff overhead use the following process;

working hours = (hours per day * days per sprint * staff) – planned leave
project hours = sum of actual (from last sprint)
staff overhead = (working hours/project hours) – 1

Story Cost x (Staff Overhead + 1) x (Estimate Risk + 1)
4 x (25%+1) x (50%+1)
= 4 x 1.25 x 1.5
= 5 to 7.25 hours


“How much is this going to cost?” – “As much as you’re willing to spend.”
“How long is this going to take?” – “As long as it necessary.”
“What am I going to get?” – “Whatever you tell us you want.”


Where a customer asks for a fixed price quote prior to agreeing to project commencement but is flexible on what is delivered and how long it takes.

  • Work in absolute customer priority order – reducing the time spent on technical helper tasks will help meet short-term budget constraints (at the cost of long term, post-project, efficiency)
  • Release in short (1-2 week) sprints – similar to longer waterfall projects, longer sprints have a tendency to cost overruns to deliver on time
  • Monitor velocity and burn rate – this is your key indicator of the cost


Where a customer asks for delivery by a certain date but is flexible in scope and cost.

  • Work in absolute business value order – increases the number of user stories complete in a given sprint (high business value = simple, moderate-high priority)

  • Enforce sprint duration – Your project will be defined by a fixed number of sprints, and extending a sprint will push out your final date


Where a customer asks for a fixed set of deliverables but is flexible in the time it takes to deliver and the cost of delivery. This is sometimes known as “heavy agile”.

  • Focus on backlog definition and estimation during Sprint 0 to ensure accurate scope definition


Where the customer asks for a fixed price quote for a fixed set of deliverables. In this
situation, the final date for delivery is flexible. As well as the points in fixed cost and fixed scope;

  • Increase the estimated risk during Sprint 0 – to ensure your quote for the project allows for unexpected delays (which would impact on your cost to deliver)
  • Update delivery date as required


Where the customer asks for a fixed price quote by a fixed time. In this situation, the exact set of features (or scope) for delivery is flexible. As well as the points in fixed cost and fixed time;

  • Calculate total cost as cost per sprint – which makes your quote to the customer very simple.


Where the customer asks for a fixed set of deliverables by a fixed time. In this situation, the total cost to the customer is flexible. As well as the points in fixed time and fixed scope;

  • Pre-assign work to sprints during Sprint 0 – which will define the scope delivery timetable.
  • Pad schedule with extra sprints – to cater to unexpected defects or technical debt
  • Increase the size of the team 3-4 sprints prior to the end of the project if required – to ensure the set of features are completed in time.


Where the customer gives no flexibility in the project.

Cancel the project – this is not an agile project. This should be run using a waterfall
methodology such as PRINCE2 (and even they are likely to fail without some flexibility)


‘Make everything as simple as possible, but not simpler.’
Albert Einstein (paraphrased), 1933


The Sprint Planning Meeting is run before the start of each Sprint and allows the customer and developers to discuss the requirements and work required for the next release. This step in the Scrum process focuses on determining the target scope of delivery for a Sprint and defines the sprint backlog. The Sprint Planning Meeting should be no more than 8 hours long (4 weeks pro rata).

The Product Owner and Scrum Master are responsible for updating the Project Backlog in preparation for the Sprint Planning meeting. This includes clarification, prioritization and in some cases investigation of the feasibility of the collated User Stories. This activity also needs to take into consideration any technical debt inherited from previous Sprints.


The first part of the sprint planning meeting aims to convert features from the backlog into a realistic goal for this sprint. The product owner is a part of this process and sets the priority of the tasks. This also provides the Product Owner with the opportunity to communicate the required scope of delivery, provide the business context and priority, and address any questions the project team may have to assist with performing the solution

decomposition and estimation steps. This part of the meeting should take no more than ¼ of the time.

Ensure that a copy of the Project Backlog has been distributed prior to the Sprint Planning meeting to provide the project team with time to consider solution options for discussion during the workshop, and prepare clarification questions for the Product Owner.

The participants for this session are as follows:

  • Product Owner
  • Scrum Master
  • Team
  • Testers


The second part of the Sprint Planning meeting is technical, and usually without the product owner. This is the solution decomposition and estimating step in the planning process and aims to estimate the effort for all features in the release and (optionally) write the test cases.

The general flow of activity in this step is described in the following diagram:

As a guideline, large tasks should be broken into tasks preferably no longer than 1 day and tasks that involve waiting should be split into separate tasks. Research tasks should have a high estimate risk. This is done to enable accurate tracking and the calculation of velocity.

For complex User Stories or those with a high number of interdependencies, it may be necessary to split the task decomposition and estimating activities across 2 days and allow the team members an opportunity to consult with external parties on the feasibility and obtain input into the estimating process.

Always remember that tasks can be created, but features can’t.

The participants for this session are as follows:

  • Scrum Master
  • Team
  • Testers


  • Prepare beforehand.
  • This is a creative, problem-solving process. Encourage brainstorming.
  • Ensure the planning room has plenty of paper, a whiteboard and a computer with Google access.


‘Treat your men as you would your own beloved sons. And they will follow you into
the deepest valley.’
Sun Tzu, ~6th Century BCE


The daily lifecycle of team activities is as follows;

1. Team members select the next Task to work on

2. Undertake the task as described

3. Commit and share the completed task with the rest of the team

4. Write and run the tests that will be used to verify they have been completed successfully. Verification, unit testing, and documentation need to be completed prior to migrating the deliverable from DEV to SIT.

The assignee for a Task may change at any of these steps. Team members will proactively interact will their colleagues and any internal parties as required to progress the assigned Task to completion, including any quality assurance and review.

The governance of the daily lifecycle is through the daily Scrum Meeting.


Based on Kanban, a task will progress through a minimum of 4 different states during its lifecycle. Each task and state should be visible to the team, product owner and customer; commonly this is done through a card wall or integrated dashboard.


The Sprint Backlog is the subset of User Stories from the Project Backlog that the Product Owner and project team agreed would be delivered for this Sprint.

The User Stories will be broken into tasks which are put into the Sprint Backlog. Based on the logical sequencing of tasks and agreed prioritization, the project team members select the next task to work on and promote this to the “In Progress” state.


In Progress, items are Tasks that are actively being worked on. This includes both development and unit testing activities. Once the task has been completed it is promoted to the “Testing” state.

In Progress, Tasks include the following types of activity being performed:

  • Analysis
  • Build
  • Unit Test
  • Documentation

When a Task has been completed the deliverable will be changed to the “Testing” state. In the case of code based artefacts, these will be promoted from the development environment to the test environment.


Blocked items are Stories and or Tasks that have upstream or downstream dependencies external to the project team that is preventing progress. These impediments are moved to this holding state to highlight these issues to the Scrum Master and Product Owner for escalation and resolution.


Testing, in this context, is performed by the team’s specialist testing resources. Unit testing is expected to be undertaken by the developers.


Tasks are considered “Done” when:

  • Code has been produced, meets development standards, and has been checked in and run against the current version in source control
  • Unit tests are written and passed
  • System tested and passed
  • Quality Assurance reviewed
  • Builds without errors for deployment
  • Relevant documentation, including diagrams, have been produced or updated and communicated

When the Sprint has completed the User Stories selected by the team to be delivered are either “Done” or “Not Done”. The decision over whether a User Story is Done is based on whether all the pre-requisite Tasks associated with this Story have been completed. The completed User Stories are presented to the Product Owner in the Sprint Review for acceptance and sign-off.


Tasks that are “Not Done” are reviewed in the context of the User Stories that they belong to and if this impacts whether the User Story can be considered delivered. The not done tasks may be rolled into a new User Story for the next Sprint, accrued as technical debt, or it may be decided that they are no longer required and are removed.



Get the highest priority feature from the Sprint Backlog. Allow developers to choose their work, don’t assign it. The backlog can be updated mid-sprint if critical changes are required.


Agile also makes some suggestions on improving the development process. These are;

  • Pair Programming: Two developers working together, the first as a coder and the
    other as a reviewer. These roles should change regularly, and the pairs themselves should switch pairs each day
  • Code Standards: A common coding style (Documentation, Names, Whitespace, etc)
  • System Metaphor: All classes and functions should be named such that they’re the purpose is understood.


Everyone must commit every day, and should never commit broken code.(Continuous Integration)


Key to Agile is transparency between the product, the team and the customers.

Customers can:

  • Attend scrums. However, they should not talk. Questions should be directed to the Product Owner or Scrum Master. An alternative is to record the scrums and make the recording available to the customer.
  • See the product and sprint backlog in its current state.
  • See the state of each task via a card wall or integrated dashboard.
  • Access a test version of the software from the development environment.



Tests are written by the Customer and Developer together and are written before the code. Both automated unit tests and user acceptance tests should be written. There is no issue with using standards such as IEEE 829 and IEEE1008 to document and write tests.

By using TDD, the team can prove how well a project is going and how close to completion. This, in turn, allows customers and product owner to make informed decisions about the project.


The tests should cover;

  • Software functions,
  • Boundary cases,
  • User interface,
  • User experience,
  • Non-functional components,
  • Performance


There are 4 types of tests that can be written.

1. Defect
2. Functionality
3. Usability
4. Data


Runs predefined tests to identify software defects

  • Create tests for each class and function
  • Create tests for all parameter combinations
  • Create tests for all edge cases
  • Create tests to examine the database for logical errors
  • Create tests to detect interface defects (Selenium)
  • Tests should be kept in the version control repository
  • Test in a clone of the production environment


Inspect the developed code for deviations from the internal code standard

  • Check for correct inline documentation (do block)
  • Check for correct variable naming conventions
  • Check for correct whitespacing conventions
  • Check for complex code that may require refactoring
  • Check for incomplete or unused functions


The following should be commented;

  • Files
  • Classes
  • Functions
  • Class Variables
  • Complex Structures

Comments should contain;

  • Description
  • Author
  • Usage
  • Parameter description
  • Return description
  • References to other functions
  • Copyright (file comments)


Calculate and display how much of the software is covered by unit tests. Aim for 80-90% code coverage.

Run any compile or make scripts. All commits should compile.


The purpose of the daily stand-up meeting is to provide a consistent focus on incremental progress and delivery demonstrated to the Product Owner. It is intended to be informative and interactive and align the team’s understanding of what is being worked on, by whom and its current status.

This meeting consists of the Product Owner, Scrum Master, and the project team and is time-boxed to 15 minutes.

All participants should answer the following three questions:

1. What did you achieve yesterday?
2. What will you achieve today?
3. What impediment may prevent you from achieving your goal today?

It is the objective of the Scrum Master to remove any impediment identified by the team.

Projects with multiple teams should hold a scrum of scrums, also timeboxed to 15 minutes, after the initial scrums. This meeting should bring together Scrum Masters from multiple teams to answer the same 3 questions as before, but relating to their teams.



Project Velocity is a measure that determines the capacity and resulting output from the project team over time. In this case, it refers to how many User Stories the project team estimates that they can deliver in the project.



Project Velocity is a measure that determines the capacity and resulting output from the project team over time. In this case, it refers to how many User Stories the project team estimates that they can deliver in the project.

The methods available to determine Project Velocity are as follows:

  • Use historical values – this assumes similarity between previous User Stories in
    terms of relative size, data, infrastructure, etc
  • Run a Sprint – derive the estimate based on observed Velocity over 2-3 Sprints
  • Make a forecast – this approach is used where we do not have existing historical values and it is not feasible to run several Sprints to observe the team’s velocity. User Stories are disaggregated and estimated at a Task level.

The scope of the project, any changes to the scope, and the planned and actual delivery of User Stories can be represented in a burndown or burnup chart. This chart can also be used to forecast when the project team will have completed all the User Stories in the Project Backlog.


Effort based Velocity determines the capacity and resulting output from the project team for a given Sprint i.e. how many User Stories can be delivered over the next two weeks. This velocity can be calculated as an average at the team level, or if there is a significant variation in the working hours as an aggregate of the individuals.

Sprint velocity is measured in terms of Potential and Forecast capacity:

  • Potential Sprint Velocity is the sum of allocated working hours for the project team
  • Forecast Sprint Velocity is the estimated productive workable hours that can be attributed to Sprint tasks i.e. takes into account Staff Overhead


Burndown and Burnup charts help managers and customers to view progress against the release, improve future estimates and identify problem trends early. The Burndown (or burn up) chart should be available to everyone involved in the project.


All about risk mitigation


Issues identified after the sprint begins or refined estimation after the sprint begins. Watch the progress carefully. If necessary review the tasks in the Sprint


Tasks are being added mid-release. Identify who is adding tasks and stop this behavior.


Features are more difficult than estimated or unexpected staffing issues. Review the tasks in the sprint.


Features are more difficult than estimated. Review the estimation process and remove tasks from the sprint.


Individual stories are too large and difficult to track. Keep each task under 1 day of work.


Fall seven times. Stand up eight.’
Old Japanese Proverb


After the Sprint, the Scrum Master should hold a Sprint Review meeting to demonstrate to the Product Owner and Customer (if different) the completed User Stories for final review for release to production. As the Product Owner should have been involved in the development and verification process on a daily basis this step should be straightforward.

The participants for this session are as follows:

  • Product Owner
  • Scrum Master
  • Project Team

During the meeting the team should:

  • Present the completed work to the Product Owner
  • Review the work that was completed
  • Review the work that was not completed. The User Stories that were not complete may move to the next Sprint.


After the Sprint Review, the Scrum master should hold a Sprint Retrospective meeting to discuss and improve on the Sprint process itself. During this meeting the team should;

1. Reflect on the sprint
2. Make any process improvements
3. Discuss what went well during the sprint
4. What could be improved during the sprint

The Sprint Retrospective provides the team with the opportunity to reflect on the Sprint just completed and drive continuous process improvement out of the learning’s taken from this.