… à l'Ecole de la V.I.E …

Le Product Owner dans le framework Scrum

Le Product Owner est un rôle clé dans la mise en place de Scrum :

– Personne de l’équipe Scrum ayant délégation des parties prenantes pour maximiser la valeur, et imputable du résultat auprès d’elles.

– Le Product Owner est la seule personne responsable de la gestion du Product Backlog.

   – Il porte la vision du produit à réaliser.

   – Il est le gardien du Product Backlog

Description du rôle de Product Owner :

Le propriétaire de produit est l’unique responsable de gérer le carnet du produit et de s’assurer de la valeur du travail de l’équipe :

– Cette personne maintient le carnet du produit et s’assure qu’il soit bien visible à tous.

– Comme tout le monde sait quels sont les éléments ayant la plus haute priorité, tous savent ce sur quoi l’équipe devra travailler.

Le propriétaire du produit est une seule et unique personne, et non pas un comité.

Le Product Owner est responsable de maximiser la valeur du travail accompli par l’équipe de développement :

– Comment cela est réalisé peut varier considérablement selon les organisations, les Scrum Teams, et les individus.

– Il travaille en interaction avec l’équipe de développement.

Pour qu’un propriétaire du produit réussisse, tous les membres de l’organisation devront respecter ses décisions :

– Les décisions prises par le propriétaire du produit sont représentées dans la sélection et la priorisation des éléments du carnet du produit.

– C’est cette visibilité accrue qui rend la tâche du propriétaire de produit à la fois exigeante, mais aussi très satisfaisante.

Le Product Owner est généralement d’un expert du domaine métier du projet.

Les compétences souhaitées du product Owner :

– bonne connaissance du domaine métier,

– maîtrise des techniques de définition de produit,

– capacité à avoir une position respectée et à prendre des décisions,

– capacité à détailler une fonctionnalité au bon moment

– esprit ouvert au changement,

– bon négociateur.

Le Product Owner et le Product Backlog

Un bon Product Owner doit bichonner son Product Backlog pour qu’il soit prêt pour le sprint qui va commencer :

– Communiquer avec les utilisateurs

– Travailler avec l’équipe sur le sprint courant

– Anticiper sur les sprints suivants

Suggestions :

Le propriétaire de produit peut aussi être un membre de l’équipe, faisant lui aussi du développement logiciel .

Cette responsabilité supplémentaire peut toutefois affecter ses capacités à bien communiquer avec les autres parties prenantes.

En aucun cas le propriétaire de produit ne peut être ScrumMaster.

Dans le cadre d’un développement commercial, le propriétaire du produit peut être le gestionnaire de produit.

Dans le cadre d’un développement maison, le propriétaire du produit pourrait être le gestionnaire de la fonction

d’affaires qui doit être automatisée.

Quizz

– Question 1

Un sponsor important du projet tient beaucoup à une fonction mais ne sait pas bien de quelle façon elle pourrait être proposée aux futurs utilisateurs du produit. Vous êtes Product Owner, que faire ?

1- Lui demander d’écrire la spécification

2- Définir une story simple sans IHM définitive et la mettre prioritaire

3- Mettre sa demande à la fin du backlog

4- Attendre qu’il dise clairement ce qu’il veut

– Réponse : 2

– Explications

La réponse 1 a été choisie par 10% des participants au QCM, la 2 par 51,5%, la 3 par 12,5% et la 4 par 26%.

Pourquoi la réponse 2 est-elle la bonne ? Procédons par élimination :

– Lui demander d’écrire la spécification

Si le sponsor ne sait pas bien comment une fonction peut être proposée, on peut penser qu’il sera encore moins capable d’écrire une spécification. Déjà quand un client sait à peu près ce qu’il veut, il ne sait pas pour autant l’écrire, alors ce n’est pas probablement pas une bonne idée de pousser ce sponsor à rédiger un document.

– Mettre sa demande à la fin du backlog

Mettre à la fin du backlog, c’est dire « on verra plus tard ». Ce plus tard, n’est pas connu, ça peut être beaucoup plus tard. Voire jamais si la story reste toujours à la fin. Comme c’est un sponsor important, on peut supposer que ce qu’il propose est important aussi et apporte de la valeur.

– Attendre qu’il dise clairement ce qu’il veut

Cela paraît plus facile que de lui demander d’écrire la spécification. Cependant l’énoncé laisse entendre que c’est dans la mise en œuvre de la fonction que le sponsor ne sait pas dire avec précision. Il n’est pas en mesure de définir l’interface homme machine, par exemple. Il ne saura pas le dire clairement, même en insistant. Il vaut mieux lui montrer quelque chose et le faire réagir.

– Définir une story simple sans IHM définitive et la mettre prioritaire

C’est pourquoi la réponse 2 est la plus adaptée. Elle permet de réduire le risque constitué par l’incertitude sur cette fonction.

– Remarque

Le Product Owner doit effectivement appliquer la solution 2. Mais en parallèle doit aller à la chasse aux besoins et propositions. Il pourrait en discuter avec le sponsor, avec les utilisateurs, l’équipe, etc afin de revenir avec une proposition d’implémentation et compléter la story.

– Extrait du Guide Scrum

La réduction de l’incertitude sur des besoins des utilisateurs est un critère de priorité. Quand un utilisateur désire une fonctionnalité mais ne sait pas de quelle façon le service doit être rendu, la solution est de lui montrer rapidement une version simple, pour obtenir son feedback. La connaissance apportée par le développement des stories relatives à cette fonctionnalité est une occasion d’améliorer le produit.

PMI-ACP exam

The PMI-ACP exam is the exam for the Agile Certfified Practitioner du Project Management Institute.

The PMI Agile Certified Practitioner (PMI-ACP)^® formally recognizes your knowledge of agile principles and your skill with agile techniques. It will make you shine even brighter to your employers, stakeholders and peers.

PMI-ACPism’s

    • Assume a small, dedicated team (7 plus or minus 2) rather than a large one
• Delivery Team includes scrum master BA, QA, developer, product owner
• Collaboration is always better than command control style management
• Face-to-face (co-location) is better than virtual
• A stable team establishes a predictable velocity
• Teams self-organize, self-govern, self-directed, make their own commitments
• Recognize you can’t know everything at the beginning of a project
• A software product can be delivered incrementally
• Questions are asked from the perspective of a team
• On the iron triangle, agile sets the time and cost, scope varies
• Terminology: Timebox, sprint (scrum), iteration (xp) are used interchangeably

Exam taking tips

– Find the question in the question text then read the rest of the text. Determine what your answer should be, and then look at the answer options shown

– Read all 4 choices and choose the BEST answer

– Quickly eliminate answers that are highly implausible

– There may be more than one “correct” answer to each question, but only one “BEST” answer

– Watch out for choices that are true statements, but do not answer the question

Options that represent broad, sweeping generalizations tend to be incorrect, so be alert for “always,” “never,” “must,” “completely,” and so forth.

Alternatively, choices that represent carefully qualified statements tend to be correct, so be alert for words such as “often,” “sometimes,” “perhaps,” “may,” and “generally.”

Reference books list

1) Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.

2) Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.

3) The Software Project Manager’s Bridge to Agility. Michele Sliger, Stacia Broderick.

4) Coaching Agile Teams. Lyssa Adkins.

5) Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.

6) Becoming Agile: …in an imperfect world. Greg Smith, Ahmed Sidky.

7) Agile Estimating and Planning. Mike Cohn

8) The Art of Agile Development by James Shore

9) User Stories Applied: For Agile Software Development. Mike Cohn.

10) Agile Project Management with Scrum. Ken Schwaber.

11) Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.

Domains and tasks for PMI-ACP

– Domain 1 : Value-driven delivery

– Domain 2 : Stakeholder engagement

– Domain 3 : Boosting team performance practices

– Domain 4 : Adaptative planning

– Domain 5 : Problem detection and resolution

– Domain 6 : Continuous improvement (Product, people, process)

 

 

Agile and the Knowledge and Skills : Level 3

The Knowledge and Skills at the Level 2 are :

 – Agile contracting methods

– Agile project accounting principles

– Applying new Agile practices

– Compliance (organization)

– Control limits for Agile projects

– Failure modes and alternatives

– Globalization, culture, and team diversity

– Innovation games

–  Principles of systems thinking (e.g., complex, adaptive, chaos)

– Regulatory compliance

– Variance and trend analysis

– Variations in Agile methods and approaches

– Vendor management

Agile contracting methods

– Contracts

Contracts suited for agile include: general service for the initial phase with fixed-price contracts for successive phases; cost-reimbursable/time and materials; not-to-exceed with fixed-fee; and a combination with incentives. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Fixed-price contracts

Fixed-price contracts, although typical of traditional projects where scope is defined ahead of time, are not well suited for agile. When scope is fixed it can deter a team from exploring out-of-scope solutions that may add value to the product. Contracts suited for agile include: general service for the initial phase with fixed-price contracts for successive phases; cost-reimbursable/time and materials; not-to-exceed with fixed-fee; and a combination with incentives. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Fixed-budget and fixed-schedule is a good agile contract

Budget and time

Time, budget, and cost estimation is an important knowledge and skill area of agile. According to Highsmith, the nature of the agile method, whereby it welcomes changing scope, means that it lends itself well to fixed budgets and a fixed schedule because changing scope makes it difficult to estimate a total cost. Generally speaking, the budget and schedule constraints are known but before a project will commence there needs to be an agreed upon set of base product functionality defined in an initiation phase; fixing scope reduces an agile team’s innovative tendency to provide improved value. For companies that are familiar with fixed-price contracts, where requirements are agreed upon before contract closing, adopting agile can be a weary initial venture. Instead, other contract vehicle types are recommended for agile efforts. These include: a general service contract for the initiation phase and separate fixed-price contracts for iterations or user stories; time-and-material contracts; not-to-exceed with fixed-fee contracts; and, incentive contracts (e.g., fixed price with incentive; cost-reimbursable with award fee). [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Agile project accounting principles

Definitions :

– Asset

An asset is defined as a potential future economic benefit that the firm controls based on past transactions.

– Capitalization

Capitalizion is a record of an expenditure as an asset rather than to treat it as an expense of the current period.

3 different stages

– 1. The Preliminary Project Stage includes conceptual formulation, evaluation and final selection of alternatives. Generally, once technical feasibility and the business case analysis are completed, the project is ready for consideration for funding approval by a company representative with budget authority. After approval, the project team participates in a kick-off, or project inception, to deepen their understanding of WHAT the customer needs and to ensure that they will deliver an economic benefit to the organization with a high-level release plan.

All costs are expensed at this stage :
High level customer requirements are determined technically feasible.
Business case has merit.
Financial resources are authorized by a company representative with budget authority.

– 2. In the Application Development Stage, the design of the chosen path, including software configurations and interfaces, marks the capitalization of project labor costs. The team now moves from WHAT to HOW. All work associated with designing, developing, coding, testing and installing of hardware are valuable features for the customer that can be capitalized. The customer may even be an internal department which will indirectly benefit the company’s net cash flows in the future. One exception at this stage is administrative overhead, training and manual data conversion which should be expensed.

Design, coding, testing: requirements prioritized for the next iteration with feedback from the customer.

Customer highly engaged throughout.

Projects have multiple iterations, and each may re-prioritize the requirements.

– 3. The Post-Implementation / Operation Stage begins after the code is in production and after final customer acceptance, testing and stabilization are completed. Typical activities in this stage include training, bug-fixing and maintenance. The costs at this stage are expensed.

Customer has accepted each iteration throughout the project, eliminating the risk of rejection in the final approval stage.

The impact of appropriately capitalizing software development expenditures can be significant, and has a number of important benefits. Conservative treatment of agile projects -expensing all costs- limits the use and extent of agile-developed software projects. Software development resources are expensive and often limited. Appropriate capital allocation of these resources is important to the competitive health of the company, and also ensures consistent reporting and capital allocation within management and across organizations for investors.

Applying new Agile practices

DSTUM or Daily stand-up meeting

A stand-up meeting (or simply « stand-up ») is a meeting with attendees typically standing. The discomfort of standing for long periods is intended to keep the meetings short.

Some software development methodologies envisage daily team-meetings to provide status updates to team members. The « semi-real-time » status allows participants to know about potential challenges as well as to coordinate efforts to resolve difficult and/or time-consuming issues. The stand-up has particular value in Agile software development processes.

Scrum-style daily stand-ups involve asking and answering three questions. Though it may not be practical to limit all discussion to these three questions, the goal is to stick as closely as possible to these questions :
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?

Whereas Kanban-style daily stand-ups focus more on :
What obstacles are impeding my progress?
(looking at the board from right to left) What has progressed?

The meeting usually takes place at the same time and place every working day. All team members are encouraged to attend, but the meetings are not postponed if some of the team members are not present. One of the crucial features is that the meeting is intended[by whom?] as a communication vehicle for team members and not as a status update to management or to other stakeholders.[citation needed] Although it is sometimes referred to as a type of status meeting, the structure of the meeting is meant to promote follow-up conversation, as well as to identify issues before they become too problematic. The practice also promotes closer working relationships in its frequency, need for follow-up conversations and short structure, which in turn result in a higher rate of knowledge transfer – a much more active intention than the typical status meeting. Team members take turns speaking, sometimes passing along a token to indicate the current person allowed to speak.[citation needed] Each member talks about progress since the last stand-up, the anticipated work until the next stand-up and any impediments, taking the opportunity to ask for help.

Team members may sometimes ask for short clarifications and make brief statements, such as « Let’s talk about this more after the meeting », but the stand-up does not usually consist of full-fledged discussions.

FDD

Feature driven development (FDD) uses a prescriptive model where the software development process is planned, managed, and tracked from the perspective of individual software features. FDD uses short iterations of two weeks or less to develop a set amount of features. The five step FDD process is: 1. Develop overall model; 2. Create the features list; 3. Plan by feature; 4. Design by feature; 5 Build by feature. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Internal and external factors

When considering whether to apply new agile practices, several internal and external factors should be considered. Internal factors include whether the project is developing new processes or products; whether the organization is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal or informal project management processes; the size, location, and skills of the project team. External factors include the industry stability and customer engagement or involvement. Generally, agile is best suited to developing new processes or products for an organization that is collaborative and emphasizes trust, adaptability, collective ownership, and has minimal project management processes by an agile/project team that is relatively small in size, is collocated, and is cross-functional in skill. Additionally, agile is known to succeed in industries that are quickly adapting to disruptive technologies as opposed to industries that are stable and perhaps inflexible to adaptive approaches. And, lastly, the component of customer involvement and engagement cannot be stressed enough; the more participation, the better. [The Art of Agile Development. James Shore.]

Iteration events

For productive iterations, each team member should attend all meetings as a “PEER” :

– Plan each iteration (Iteration Planning)

– Expect daily updates (Daily Stand-Up)

– Examine product results (Iteration Review)

– Reinvent processes for next iteration (Iteration Retrospective)

Planning game

Extreme programming (XP) uses the planning game to prioritize features based on user stories and release requirements. [The Art of Agile Development. James Shore.]

Planning poker

Planning poker is a popular agile game used to estimate the relative work effort of developing a user story. Each team member has a deck of cards with various numbered values which he or she can draw from to « play (showing one card) » to indicate an estimated point value of developing a user story. [Coaching Agile Teams. Lyssa Adkins.]

Scrum

Scrum emphasizes, in part, the following principles: always have a product you can theoretically ship, speak a common language, and continuously test the product as you build it. [Agile Project Management with Scrum. Ken Schwaber.]

The core roles in scrum are the product owner, scrum master and development team. [Agile Project Management with Scrum. Ken Schwaber.]

The product development team decides what could be achieved by the next sprint. PO gives the priority, team decides the capacity.

Whenever a project needs many people, the guideline is to form multiple scrum teams sprinting individually that do daily scrum followed by a daily or weekly Scrum of Scrums at which one member from each scrum team meet to synchronize their work for any dependencies.

– Product Owner

PO is solely responsible for change management at any stage. The team should provide inputs to the PO like impact analysis on the basis of which the PO needs to make a decision on the priority of the change.

In scrum Product Owner is authorized and responsible to identify what all need to be built, so team member should notify this to PO and PO should take call on this.

XP

Extreme Programming (XP) uses the following practices: pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards, open workspace, and team rules [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

A project manager in an XP team ensures that the team works well with the rest of the organization. A PM is more focused in managing external stakeholders.

– Refactoring

It is always recommended to refactor the code if it is more than complex, but doing this may require a good amount of time so it’s better to get this work first added in product backlog and then accomplish it. If you can do it without impacting the current sprint goal you can create a task in sprint backlog for refactoring the module and start working on it.

Compliance (organization)

Compliance with a company’s code of ethics and professional conduct is standard practice in agile. [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Control limits for Agile projects

Control limits – those which set an objective range to indicate whether a process is controlled or stabilized or defect free (e.g., within three sigmas of the mean) – may be used in an agile project. Generally, a control limit of three-sigma (s) is used on a Shewhart control chart. A sigma refers to one standard deviation. So three sigmas indicates a limit three standard deviations away from the mean in both the positive and negative direction. This applies to normal data, where a normal distribution curve has been obtained. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Failure modes and alternatives

The top 12 causes of agile failure (failure modes) according to Aaron Sanders :

1. A checkbook commitment doesn’t automatically cause organizational change or support.

2. Culture doesn’t support change.

3. Culture does not have retrospectives or performs them poorly.

4. Standards and quality are lost in a race to project closing.

5. Lack of collaboration in planning.

6. None or too many Product Owners.

7. Poor project leadership or scrum master that doesn’t place trust in the team and allow it to be self-organizing and self-disciplined.

8. No on-site agile promoter or coach.

9. Lack of a well built, high-performance team.

10. Accrued technical debt if strict testing standards are not upheld.

11. Culture maintains traditional performance appraisals where individuals are honored and the team aspect is lost.

12. A reversion to the traditional or ‘old-way’ of doing business occurs because change is hard.

[Coaching Agile Teams. Lyssa Adkins.]

Globalization, culture, and team diversity

– Common language

Scrum emphasizes, in part, the following principles: always have a product you can theoretically ship, speak a common language, and continuously test the product as you build it. [Agile Project Management with Scrum. Ken Schwaber.]

A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction. However, collocation isn’t always feasible in today’s multinational environment. For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible. Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Changing company culture is typically the most difficult when migrating to an agile framework. [The Art of Agile Development. James Shore.]

Innovation games

The phrase innovation game refers to a form of primary market research developed by Luke Hohmann where customers play a set of directed games as a means of generating feedback about a product or service. The research is primary because the data collected is gathered directly from customers or prospects and is intended to answer a specific research question. (Secondary research is data collected previously by others, usually through primary research, that may or may not address a specific research question.) “Customers” who play innovation games are commonly direct recipients or consumers of a specific product or service. In some cases, though, game players may be any person or system who is or would be affected by a product or service.

Innovation games are directed by a facilitator whose responsibilities include :

– explaining the game(s) to be played;

– controlling the pacing and tempo of each game;

– monitoring participation levels; and,

– managing time of the overall game-play event.

The successful operation of an innovation game relies on collaborative play among the participants and a set of observers drawn from disparate functional groups within an organization. For example, a typical game setting for a word processing software might include participants drawn from two or three corporate customers along with observers comprising the product’s quality assurance manager, technical architect, product manager, developer, sales executive, or any one else on the product team. Arguably, the most important observer is the product manager because that person is responsible for acting on the data generated by the game. However, a single observer cannot possible capture all of the nonverbal and nuanced communication that players exhibit, so all observers play a significant and irreplaceable role in the effective utility of the game.

12 innovation games

There are at least 12 unique innovation games (and any number of new games derived by combining elements of these 12 games) :

– 20/20 Vision

Several potential product features appear on a shuffled set of note cards, one feature per card. The facilitator tapes the first card face-out onto the wall and displays each of the remaining cards one at a time to the participants, asking if the feature on the card is more or less important than the feature on the wall. No two features are allowed to be of equal importance.

– Buy a Feature

Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds.

– Give Them a Hot Tub

Several potential product features appear on a shuffled set of note cards, one feature per card. Some of the proposed features are completely outrageous, such as a “crush rocks” setting for a new food blender. Observers note what happens when a customer uncovers one of these outrageous features.

– Me and My Shadow

Observers carefully record a participant using a product or service. Observers sit next to the participant to watch for and listen to actions, expressions, comments, and suggestions. Observers ask questions of the participant, such as “Why are you doing that,” or “what are you thinking at this moment”.

– Product Box

Participants imagine that they’re selling a vendor’s product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy.

– Prune the Product Tree

A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements.

– Remember the Future

Participants imagine a time in the future when they will have been using the product almost continuously between now and then. (“Future” may be expressed in months, years, or some other time frame.) Participants then write down exactly what the product will have done to make them happy, successful, rich, safe, secure, etc.

– Show and Tell

Participants bring in examples of artifacts created or modified by the product or service. Participants explain why these artifacts are important, and how and when they are used.

– Speed Boat

A drawing of a boat appears on a white board or sheet of butcher paper. Anchors “attached” to the boat prevent it from moving quickly through the water. The boat represents a product or system, and the anchors are features that the participants don’t like. The lower the anchor, the more debilitating the feature.

– Spider Web

A product name appears at the center of a circle drawn in the middle of a whiteboard. Participants draw other products and services, explaining how, when, and why they are used. Participants then draw lines that link these additional services to each other and to the product’s circle.

– Start Your Day

Participants describe their daily, weekly, monthly, and yearly events related to their use of a product. Descriptions are written on pre-printed, poster-sized calendars or timelines taped to the walls. Participants include events with time frames that match the product’s expected lifecycle or release cycle. Participants may also include one-time events (particularly horrible days where everything goes wrong) and describe how the product helps or hinders as the event unfolds.

– The Apprentice

An engineer or product developer uses the product as an end-user. For example, if the system is used for data entry, the developer enters data for a couple of days. Observers record the engineer’s actions, expressions, comments, and suggestions.

Selecting an appropriate game

While any number or variety of innovation games may be invented, combined, or adapted from other game environments, all such games have strengths and weaknesses that constrain their applicability to specific kinds of problems.

These strengths and weaknesses are expressed as six separate dimensions :

– the degree of open-ended exploration: how much or how little the participants are constrained in their interactions

– the degree of scalability: the number of customers who can play the game at any one time

– the degree of physical preparation: what kinds of supplies or materials are necessary to play the game

– the degree of market preparation: how much background effort is necessary to provide data or content for the game

– the degree of customer preparation: what pre-game activities, if any, to require of the participants before entering the game environment

– the time frame of action: how long after the game completes before the participant expects a product’s improvement to reflect the game’s results

Principles of systems thinking (e.g., complex, adaptive, chaos)

A complex adaptive system, or CAS, is a system composed of interacting, adaptive agents or components. The term is used in agile to remind practitioners that the development of a product is adaptive in that previous interactions, events, decisions influence future behavior. The term chaordic (a made up word blending chaotic and order) is sometimes used when describing CASs. Literature points to three key characteristics of chaordic projects: alignment and cooperation, emergence and self-organization, and learning and adaptation. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Regulatory compliance

Although in agile project management, it is generally practiced to generate minimal documentation to support the project, some specific documents, like those required by regulatory bodies need to be created to comply with local and federal law. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Compliance with a company’s code of ethics and professional conduct is standard practice in agile. [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Variance and trend analysis

Unlike traditional project management methods that evaluate risk and variance and trends in formal meetings, agile incorporates risk analysis and variance and trend analysis into iteration review meetings. Risk and variance and trend analysis may be performed in agile using information radiators, like a risk burndown chart, and the use of traditional earned value management (EVM) to measure cost and schedule variance (CV and SV, respectively). [Agile Estimating and Planning. Mike Cohn.]

EVM

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). BAC is the total project budget. [Agile Estimating and Planning. Mike Cohn.]

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). CV and SV can be converted into performance indicators of CPI and SPI, respectively, and tracked and charted to show progress over time. BAC is the total project budget. AC is the actual cost incurred to date. PV is the planned value of work at a given time in a project; you can calculate it by multiplying the BAC by the ratio of current week/scheduled weeks (e.g., 5 weeks into a 15 week $15,000 project = $5,000 PV). EV is value of work actually completed or earned (e.g., you have completed 50% of the project by week 5 of a 15 week $15,000 project = $7,500 EV). CV is the difference between what a project has earned to date and cost to date (i.e., CV = EV – AC). SV is the difference between what a project has earned to date and what it was planned to earn to date (i.e., SV = EV – PV). CPI is a ratio that expresses cost performance. CPI = EV/AC. If CPI > 1, the project is earning more than spending; and if CPI 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule. [Agile Estimating and Planning. Mike Cohn.]

– SPI

Schedule Performance Index (SPI). SPI is a ratio that expresses schedule performance. SPI = EV / PV. If SPI > 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule. AC is the actual cost the project has incurred to date. [Agile Estimating and Planning. Mike Cohn.]

Variations in Agile methods and approaches

XP primary principles include: collective ownership, continuous integration, energized work, shared workspaces, and an on-site customer. [The Art of Agile Development. James Shore.]

Vendor management

Approch

The Agile Manifesto values customer collaboration over contract negotiation which sets an important tone for procurement relationships on agile projects. The Agile Manifesto sets forth the idea that a buyer and seller work together to create products and governs the entire procurement process.

Determining need and selecting a vendor the agile management way

On agile projects, procurement starts when the development team decides it needs a tool from or the services of another company in order to create the product. The development team and the scrum master work with the product owner to procure any necessary funds.

The development team may need to compare tools and vendors. After you choose what to buy and where to get it, the process is usually straightforward: Make the purchase, take delivery, and procurement is then complete.

Procuring services is usually longer and more complex than with tools.

Some agile-specific considerations for selecting a services vendor include

Whether the vendor can work in an agile project environment and, if so, how much experience the vendor has

Whether the vendor can work on-site with the development team

Whether the relationship between the vendor and the scrum team is likely to be positive and collaborative

Contracts and cost approaches for services the agile management way

– Evaluating cost structures for an agile project

Fixed-price projects: A vendor works on the product and creates releases until the vendor spends all the money in the budget, or until it delivers enough product features, whichever comes first.

Fixed-time projects with a specific deadline: For example, you may need to launch a product for a specific event or to coincide with the release of another product. With fixed-time projects, you determine costs based on the cost of the vendor’s team for the duration of the project, along with any additional resource costs, such as hardware or software.

Time-and-materials projects: Work with the vendor lasts until enough product functionality is complete, without regard to total project cost. You know the total project cost at the end of the project, after your stakeholders determine that the product has enough features to call the project complete.

Not-to-exceed projects: Projects in which time and materials have a fixed-price cap.

– Creating a contract for an agile project

The scrum master is generally responsible for initiating the contract creation, negotiating the contract details, and routing the contract through any necessary internal approvals, including review by a legal or procurement expert.

– At the very least, most contracts have legal language describing the parties and the work, the budget, the cost approach, and payment terms. A contract for an agile project may also include:

– A description of the work the vendor will complete :

The vendor may have its own product vision statement, which can be a good starting point to describe the vendor’s work.

– Agile approaches the vendor may use, including :

Meetings the vendor will attend, such as the daily scrum, sprint planning, sprint review, and sprint retrospective

Delivery of working functionality at the end of each sprint

The definition of done — developed, tested, integrated, and documented — per an agreement between the product owner and the development team

Artifacts the vendor will provide, such as a sprint backlog with a burndown chart

People the vendor will have on the project, such as the development team

Whether the vendor will work on-site

Whether the vendor will work with its own scrum master and product owner or if it will work with your scrum master and product owner

A definition of what may constitute the end of the engagement: the end of a fixed budget or fixed time, or enough working functionality

If the vendor doesn’t use agile approaches, describe how the vendor and the vendor’s work integrate with the buyer’s development team and sprints.

Working with a vendor on an agile management project

How you work with a vendor on an agile project depends in part upon the vendor team’s structure. In an ideal situation, vendor teams are fully integrated with the buyer’s organization. The vendor’s team members are collocated with the buyer’s scrum team.

Some development teams include vendor team members in their daily scrum meetings. This can be a good way to get an idea of what the vendor team is doing every day and to help the development team work more closely with the vendor. You can also invite vendors to your sprint reviews to keep them informed on your progress.

If the vendor can’t work on-site at the buyer’s company, it can still be part of the buyer’s scrum team. If a vendor can’t be collocated, or if the vendor is responsible for a discrete, separate part of the product, the vendor may have a separate scrum team working on the same sprint schedule as the buyer’s scrum team.

If a vendor doesn’t use agile project management processes, the vendor’s team works separately from the buyer’s scrum team, outside of the sprints, and on its own schedule. The vendor’s traditional project manager helps ensure that the vendor can deliver its services when the development team needs them. The buyer’s scrum master may need to step in if the vendor’s processes or timeline becomes a roadblock or disruption for the development team.

Closing a contract on an agile management project

When a vendor completes work on a contract, the buyer’s scrum master usually has some final tasks.

If the project finishes according to the contract terms, the scrum master may acknowledge the end of the contract in writing. If the project is a time-and-materials project, the scrum master should definitely do so to ensure that the vendor doesn’t keep working on lower-priority requirements — and billing for them.

The scrum master may be responsible for notifying the buyer’s company accounting department to ensure that the vendor is paid properly.

If the project finishes before the contract dictates the end, the scrum master needs to notify the vendor in writing and follow any early termination instructions from the contract.

Most large organizations maintain a vendor profiling system to manage the relationships with their vendors. This database contains information about skills, rates, and former projects that have been run with each vendor. More or less, sophisticated ranking systems categorize the vendors from strategic partners to vendors the company wants to get rid of. Used wisely, these systems can establish both a business and a legal relationship with your vendors in which you don’t have to step on the thin ice of contracting a single agile project.

Therefore, rather than focusing on vendor process certifications, size, and rates, the ranking should focus on criteria such as the following :
– Productivity
– System quality
– Flexibility
– Collaboration level

Beyond a single effort, agile development is about building trust. A special vendor management database may help large organizations here — as long as the vendor evaluation is based on « soft » criteria, such as collaboration level and software quality, rather than on « hard » facts, such as rates and willingness to subordinate during negotiations.

Agile and the Knowledge and Skills : Level 2

The Knowledge and Skills at the Level 2 are :

– Agile frameworks and terminology

– Building high-performance teams

– Colocation (geographic proximity) / distributed teams

– Continuous improvement processes

– Elements of a project charter for an Agile project

– Facilitation methods

– Participatory decision models (e.g., inputbased, shared collaboration, command)

– PMI’s Code of Ethics and Professional Conduct

– Process analysis techniques

– Self assessment

– Value-based analysis

Agile frameworks and terminology

Common frameworks or methodologies used within agile include: scrum, extreme programming (XP), lean software development, crystal, feature driven development (FDD), dynamic systems development method (DSDM), agile unified process (AUP). [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Agile methods offer several benefits including faster time to market, more business value and improved stakeholder satisfaction. For planning, agile does not recommend heavy upfront planning. Instead, it recommends an initial high-level plan which is re-visited on several occasions throughout the project.

Agile methods work well where there is uncertainty in the environment and the results are driven by people rather than process. Heavy-weight methods canvass formality and discipline in order to work the intricacies of the project. In opposition, agile methods favor creativity, improvisation, and nimbleness to negotiate with project hazards. In addition, agile methods welcome change and alternately adapt to the new conditions. Heavy methods are more pessimistic at handling change and try to get all things worked out in the first instance.

– Agile Unified Process (AUP)

– Crystal methodologies

– DSDM

– FDD

– Lean Software Development

– Scrum

– XP

Building high-performance teams

Building a high-performance team is critical to any project’s success. A high performance team has the right team members, is empowered, has built trust, works at a sustainable pace, has consistently high velocity/productivity, takes regular time for reflection to review work, has a team lead that removes any obstacles and provides mentoring and coaching, is self-organized and self-disciplined, and is collocated. Several management techniques can be used to build or foster a high-performance team environment, some techniques include: removing obstacles that slow down a team’s performance, having high expectations of team performance, and coaching and mentoring the team to achieve its best performance. [Coaching Agile Teams. Lyssa Adkins.]

A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction. However, collocation isn’t always feasible in today’s multinational environment. For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible. Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences. [The Art of Agile Development. James Shore.]

High-performance teams differ from low-performance teams with how they deal with conflict. Conflict is inevitable even for the most experienced agile team. The difference is that high-performance teams approach conflict with an open mind and as self-organizing often navigate and resolve conflict organically. [Coaching Agile Teams. Lyssa Adkins.]

Tacit knowledge is the « sum of all knowledge from all people on a project team. » [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Taking the team out to lunch for bonding and trust building. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Business case development

Business case development is an important initial step in agile project management. The business case is a concise document that outlines the project’s vision, goals, strategies for achieving goals, milestones, required investment and expected return/payback. A business case articulates the why and how a project will deliver value to a customer. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Colocation (geographic proximity) / distributed teams

 Building a high-performance team is critical to any project’s success. A high performance team has the right team members, is empowered, has built trust, works at a sustainable pace, has consistently high velocity/productivity, takes regular time for reflection to review work, has a team lead that removes any obstacles and provides mentoring and coaching, is self-organized and self-disciplined, and is collocated. Several management techniques can be used to build or foster a high-performance team environment, some techniques include: removing obstacles that slow down a team’s performance, having high expectations of team performance, and coaching and mentoring the team to achieve its best performance. [Coaching Agile Teams. Lyssa Adkins.]

A high-performance agile team is one that is ideally collocated for osmotic communication and face-to-face interaction. However, collocation isn’t always feasible in today’s multinational environment. For distributed teams, several practices are available to provide the best form of effective communication in the absence of being collocated: team intranet sites, virtual team rooms, and video conferencing over e-mail when possible. Geographic separation, especially on a world-wide scale, causes the team to consider language and cultural differences, and time zone differences. [The Art of Agile Development. James Shore.]

Continuous improvement processes

– Continuous improvement

Agile project management places strong emphasis on ‘continuous improvement.’ Continuous improvement processes are built into the agile methodology, from customers providing feedback after each iteration to the team reserving time to reflect on its performance through retrospectives after each iteration. Ongoing unit and integration testing and keeping up with technological/industry developments also play a part in the continuous improvement process. Continuous improvement is also a key principle in the lean methodology, where a focus of removing waste from the value stream is held. [The Art of Agile Development. James Shore.]

PDCA was made popular by Dr W. Edwards Deming, who is considered by many to be the father of modern quality control.

– Kaizen

The Japanese word « kaizen » means change for the better. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

The word kaizen means “continuous improvement.” It is a system of continuous improvement in quality, technology, processes, company culture, productivity, safety, and leadership. It comes from the Japanese words (“kai”) which means “change” or “to correct” and (“zen”) which means “good.”

– Reflection or retrospectives

During reflection or retrospectives, an agile team reserves time to reflect on the work it has completed with the objective of continuous improvement. In these self-assessment/team-assessment events, topics can include: lessons learned from successes and failures; team standards that worked, failed, or were not properly followed; and other areas of improvement. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products.

Elements of a project charter for an Agile project

The project charter is an important governing document that requires all stakeholder participation. Although experts recommend it not be longer than a page in length, creating a project charter can be challenging, as all stakeholders must participate and come to a consensus. Three key elements should be included in a project charter: vision, mission, and success criteria. Vision is the ‘why’ or rationale of a project. Mission is the ‘what’ of the project and describes what the team will accomplish to reach the vision. Success criteria are management metrics that define ‘how’ the project will be deemed successful. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Facilitation methods

As a project leader or scrum master, effective facilitation methods are critical for building a high-performance and motivated team. Facilitation of meetings, discussions, demonstrations, etc., is a constant on an agile project. Some general facilitation methods include: using a small number of people for brainstorming events; hosting events in a non-threatening/comfortable environment; having an agenda that is shared with the group ahead of time; using open-ended questions instead of closed-ended questions; including a diverse representation to gain a broader perspective of the topic. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Problem-solving techniques

Literally thousands of decisions are made in the course of a project. Many of these decisions are made in response to problems that inevitably arise and confront the agile team. Therefore it is essential that an agile team is properly versed in problem-solving strategies, tools, and techniques. Some common problem-solving techniques include: ask it loud; revisit the problem; 5Y; sunk cost fallacy; devil’s advocate; be kind, rewind; asking probing questions; and reflective/active listening. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Participatory decision models (e.g., inputbased, shared collaboration, command)

To build trust among the team, agile believes heavily in participatory decision models where team members collaborate to make decisions. Although a team leader or scrum master will need to make some decisions individually, many decisions can be made by the team collectively. These agile principles are also known as collective ownership, self-organization, and self-discipline. In collective ownership, the team members are equally responsible for project results and are empowered to participate in decision making and problem solving processes. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

PMI’s Code of Ethics and Professional Conduct

The Project Management Institute (PMI) outlines a professional code of conduct in the PMI Code of Ethics and Professional Conduct document. [PMI Code of Ethics and Professional Conduct. Project Management Institute.]

Process analysis techniques

– Value stream mapping

Value stream mapping is a collaborative process analysis technique where a diverse team depicts/maps a process to identify where waste occurs and where improvements can be made. It is an example of a process analysis technique. Like value stream mapping, process mapping is also used to map a process to identify bottlenecks (places where processing slows and inventory can build). [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

To build trust among the team, agile believes heavily in participatory decision models where team members collaborate to make decisions. Although a team leader or scrum master will need to make some decisions individually, many decisions can be made by the team collectively. These agile principles are also known as collective ownership, self-organization, and self-discipline. In collective ownership, the team members are equally responsible for project results and are empowered to participate in decision making and problem solving processes. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

– Self assessment

In social psychology, self-assessment is the process of looking at oneself in order to assess aspects that are important to one’s identity. It is one of the motives that drive self-evaluation, along with self-verification and self-enhancement. Sedikides (1993) suggests that the self-assessment motive will prompt people to seek information to confirm their uncertain self-concept rather than their certain self-concept and at the same time people use self-assessment to enhance their certainty of their own self-knowledge.[1][2] However, the self-assessment motive could be seen as quite different from the other two self-evaluation motives. Unlike the other two motives through self-assessment people are interested in the accuracy of their current self view, rather than improving their self-view. This makes self-assessment the only self-evaluative motive that may cause a person’s self-esteem to be damaged.

So if through self-assessing there is a possibility that a person’s self-concept, or self-esteem is going to be damaged why would this be a motive of self-evaluation, surely it would be better to only self-verify and self-enhance and not to risk damaging self-esteem? Trope suggests in his chapter « Self-Enhancement and Self Assessment in Achievement Behaviour »[3] that self-assessment is a way in which self-esteem can be enhanced in the future. For example self-assessment may mean that in the short-term self-assessment may cause harm to a person’s self-concept through realising that they may not have achieved as highly as they may like; however in the long term this may mean that they work harder in order to achieve greater things in the future, and as a result their self-esteem would be enhanced further than where it had been before self-assessment.

Within the self-evaluation motives however there are some interesting interactions. Self-assessment is found a lot of the time to be associated with self-enhancement as the two motives seem to contradict each other with opposing aims; whereas the motive to self-assess sees it as important to ensure that the self-concept is accurate the motive to self-enhance sees it as important to boost the self-concept in order to protect it from any negative feedback.

Self assessment :

– Learning all the life

– Learning to know : the formal education system

– Learning to do : vocational learning

– Learning to live together : learning for social cohesion

– Learning to be : learning as personal growth

8 keys competences of self assessment :

1) Communication in the mother tongue, which is the ability to express and interpret concepts, thoughts, feelings, facts and opinions in both oral and written form (listening, speaking, reading and writing) and to interact linguistically in an appropriate and creative way in a full range of societal and cultural contexts.

2) Communication in foreign languages, which involves, in addition to the main skill dimensions of communication in the mother tongue, mediation and intercultural understanding. The level of proficiency depends on several factors and the capacity for listening, speaking, reading and writing.

3) Mathematical competence and basic competences in science and technology. Mathematical competence is the ability to develop and apply mathematical thinking in order to solve a range of problems in everyday situations, with the emphasis being placed on process, activity and knowledge. Basic competences in science and technology refer to the mastery, use and application of knowledge and methodologies that explain the natural world. These involve an understanding of the changes caused by human activity and the responsibility of each individual as a citizen.

4) Digital competence involves the confident and critical use of information society technology (IST) and thus basic skills in information and communication technology (ICT).

5) Learning to learn is related to learning, the ability to pursue and organise one’s own learning, either individually or in groups, in accordance with one’s own needs, and awareness of methods and opportunities.

6) Social and civic competences. Social competence refers to personal, interpersonal and intercultural competence and all forms of behaviour that equip individuals to participate in an effective and constructive way in social and working life. It is linked to personal and social well-being. An understanding of codes of conduct and customs in the different environments in which individuals operate is essential. Civic competence, and particularly knowledge of social and political concepts and structures (democracy, justice, equality, citizenship and civil rights), equips individuals to engage in active and democratic participation.

7) Sense of initiative and entrepreneurship is the ability to turn ideas into action. It involves creativity, innovation and risk-taking, as well as the ability to plan and manage projects in order to achieve objectives. The individual is aware of the context of his/her work and is able to seize opportunities that arise. It is the foundation for acquiring more specific skills and knowledge needed by those establishing or contributing to social or commercial activity. This should include awareness of ethical values and promote good governance.;

8) Cultural awareness and expression, which involves appreciation of the importance of the creative expression of ideas, experiences and emotions in a range of media (music, performing arts, literature and the visual arts).

These key competences are all interdependent, and the emphasis in each case is on critical thinking, creativity, initiative, problem solving, risk assessment, decision taking and constructive management of feelings.

The self-assessment process

1) The user, in a first step, is asked to choose one to start the self-assessment of key competence performance with, from the list of 8 key competences of Lifelong Learning named by the European Commission (2007);[9]

2) In a next step five generic situations are presented, each one describing a situation in which the chosen key competence is performed in a common setting.

Each of the five situations corresponding to the following five levels of mastery :

– Level 1 can do when guided (in known situations),

– Level 2 can do, can choose (in known situations),

– Level 3 can combine, can design (also in unknown situations),

– Level 4 can improve, can extend, Level 5 can explain.

3) Five different clusters of the chosen key competence are presented. These clusters are well grounded in Vintage research considering projects and publications throughout European countries and Framework. After deciding for a cluster the user is presented a situation in which the key competence in the chosen domain is performed. Again situations, meant to be broad enough to apply to many common experiences, yet specific enough to identify what a performance in a certain key competence and domain requires, meant to refer to daily life settings, support the user in the reflective abilities to relate own experiences and performances to the described situations.

4) The user is asked to note and reflect upon own experiences and collect these in the Vintage portfolio as documentation of personal key competence experiences to be used in further development or to be included in e.g. the European CV (Cedefop/European Commission 2004). Amongst others this stresses the importance and relevance of lifelong learning, be it in formal, non-formal or in-formal settings.

5) The quality of the performance is, consequently to the premises of self-assessment, evaluated by the user himself, ranking personal performances on the following four dimensions of qualities:

1. Reflective

2. Autonomous

3. Self-directed – Self-regulated

4. Effective

The four quality dimensions thereby refer to themes such as critical thinking, creativity, initiative, problem-solving, risk assessment, decision-taking and constructive management of feelings.

Value-based analysis

Value-based analysis strives to understand how value, as defined by the customer, relates to various components of the product, like features and tasks. Features are often prioritized with prioritization based on value and risk. Prioritization can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Agile and the Knowledge and Skills : Level 1

The Knowledge and Skills at the Level 1 are :

– Active listening

– Agile Manifesto values and principles

– Assessing and incorporating community and stakeholder values

– Brainstorming techniques

– Building empowered teams

– Coaching and mentoring within teams

– Communications management

– Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)

– Incremental delivery

– Knowledge sharing

– Leadership tools and techniques

– Prioritization

– Problem-solving strategies, tools, and techniques

– Project and quality standards for Agile projects

– Stakeholder management

– Team motivation

– Time, budget, and cost estimation

– Value-based decomposition and prioritization

Active listening

One communication technique to reduce misunderstanding and miscommunication is active listening. A well run agile project necessitates both good listeners and communicators, active listening helps work towards both of these necessities. The basics of active listening include: 1) Being present and focusing your attention on the speaker. 2) Taking notes instead of interrupting. 3) Paraphrasing to confirm and review what you have heard. 4) Summarizing the conversation once it has concluded for posterity. Using open ended questions, good body language, and silence can help improve listening skills. [Coaching Agile Teams. Lyssa Adkins.]

Basics :
1) Being present and focusing your attention on the speaker
2) Taking notes instead of interrupting
3) Paraphrasing to confirm and review what you have heard
4) Summarizing the conversation once it has concluded for posterity

Using open ended questions, good body language, and silence can help improve listening skills.

Agile Manifesto values and principles

– Agile manifesto

The authors of Agile Manifesto are the founding members of Agile Alliance. Ken Schwaber founded Agile Alliance in 2001 after the Agile Manifesto was published.

Agile Manifesto values customer collaboration more than contract negotiation. Agile Manifesto values include the following: Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Values

– 4 values

The Agile Manifesto defines four values. The four values list primary values and secondary values, with primary values superseding secondary values. The values are 1) individuals and interactions over processes and tools, 2) working software over comprehensive documentation, 3) customer collaboration over contract negotiation, and 4) responding to change over following a plan. [Manifesto for Agile Software Development. Agile Alliance.]

            – Individuals and interactions over process and tools

This talks about value of empowering the team that far outstrips the benefits derived from processes and tools. We must constantly be aware that it is our people who actually do all the value added work, and respect for people is a comforting and fundamental principle of Lean and Agile.

Agile projects are built around motivated individuals and the team organize themselves without the command and control structure. The rest of the options are not correct since agile teams are highly disciplined, there is more planning in agile projects than the traditional projects and also the teams are motivated and empowered which enables them to deliver at sustainable pace.

– Working software over comprehensive documentation

            – Customer collaboration over contract negotiation

– Responding to change over following a plan

Responding to change over following a plan – Agile Manifesto. The principle doesn’t devalue planning—just sticking to the plan. Planning is valuable in itself, and because the plan helps us recognize when things have changed; it helps us understand the implications of change, how we need to adjust, and the likely cost. The important thing is that, as we make plans, we understand that the plan may have to change. Planning is an ongoing time-boxed activity.

Though Agile Manifesto states that it values responding to change over following a plan, it should not be constructed as there is no need for planning on agile projects. In fact, Agile projects do overall more planning than the traditional ones.

– Secondary values

The agile secondary values include: documentation of software, processes and tools, contract negotiation, and following project plans. [Manifesto for Agile Software Development. Agile Alliance.]

– If you don’t follow the four Agile Manifesto values “It Will Create Risks”.

Principles

The Agile Manifesto defines 12 supporting principles. Agile principles include :

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 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. Agile Alliance.]

12 principles :

– Customer satisfaction
Satisfy the customer by delivering software that provides value to the customer early, and often.

– Welcoming change
It is expected that requirements will change and these changes are welcomed.

– Frequent delivery
Get working software delivered to the customer as soon as possible.

– Colocated teams
Bring the project team and the customers together, preferably collocated in the same physical area.

– Motivated individuals
Build your team around motivated individuals and trust them to do the work.

– Face-to-face contacts
Face-to-Face communication is the most effective method for exchanging ideas.

– Working software
True customer value is realized by delivering results, which is represented in terms of working software.

– Constant pace
Sustain a constant development pace to minimize project team burnout and maximize optimal performance indefinitely.

– Continuous attention
Continuous Attention to technical excellence and good design will allow the project team to respond more quickly and easily to change.

– Simplicity
Maximize the amount of work not done.

In agile processes, there is a strong taste of minimalism. Include only what everybody needs rather than what anybody needs. There is a point in time when any additional effort put into work product will increase its cost without increasing its value. It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.

– Self-organization

The team decides how the tasks will be allocated, as opposed to being dictated to them.

The best architectures, requirements and designs emerge from self-organizing teams. The emergent properties for a complex project are best generated from self-organizing teams in which the interactions are high and processes are low.

– Regular reflections
Schedule Retrospectives to constantly reflect on the work that was completed and find ways to improve during the next iteration.

The Agile Manifesto Principles as Months :
– January
Just Sit Together (Collocated Teams)
– February
Face-to-Face Contact (Face-to-Face Contact)
– March
Motivated Individuals (Motivated Individuals)
– April
Attention (Continuous Attention)
– May
Maintain a Constant Pace (Constant Pace)
– June
Jump on Improvements (Regular Reflection)
– July
Juggle Changes (Welcomed Changes)
– August
Augment Customer Satisfaction (Customer Satisfaction)
– September
Simplicity (Simplicity)
– October
Organization (Self-Organization)
– November
New Changes (Welcomed Changes)
– December
Deliver Frequently (Frequent Delivery)

The principles behind Agile Manifesto states that “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Answer ‘a’ is incorrect since embracing change will not curb uncontrolled changes. Answer ‘b’ and ‘d’ are again not reasons why Agile insists on embracing changing requirements.

The agile principles state without ambiguity that business people and developers must work together daily throughout the project. Answer ‘b’ says ‘regularly’ which may not be ‘daily’. Agile developers adopt practices such as on-site customer and active stakeholder participation which enable stakeholders to be actively involved with software development.

Fixed scope is not in line with the agile principles. One of the core principle of agile is to welcome changing requirements even late in development cycle for customer’s competitive advantage. The rest of the options are in line with Agile principles.

Agile project management

We apply empirical process control where underlying mechanisms are not well defined.

Agile project management differs fundamentally from traditional project management in the following ways: High-level project scope, multiple iterations of product development, teams are self-organizing, extensive customer involvement. [Manifesto for Agile Software Development. Agile Alliance.]

Key characteristics of agile project management include: continuous improvement, cross-functional teams, short iterations, an incremental approach, and business priorities and customer value. [The Art of Agile Development. James Shore.]

Jim Highsmith’s agile project management model consists of the following sequential five phases: Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

5 phases

– Envisioning

The focus in the envisioning phase is on project vision, scope (and requirements), project schedule, and assembling a project team. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Speculating

The focus in the speculation phase is on estimating iteration and release plans, defining feature breakdown, developing a rough project plan, considering project risk and risk mitigation strategies, and estimating project costs. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Exploring

In the exploring phase, the agile team focuses on designing, building, and testing product features. This occurs within useful increments to the customer. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

When conducting the exploring phase, project leaders assist developers by removing any obstacles or constraints that my impeded progress, and managing interaction with product owners, customers, and other stakeholders. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Adapting

In the adapting phase, the agile team encourages feedback of the latest deliverable of an iteration. From the feedback, the team adapts product features and plans for the subsequent iteration. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

In the adapting phase, the agile team leader may make adjustments to the team makeup, like problems raised by team members, if any team dynamic problems arise. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Closing

In the closing phase, the agile team completes all remaining project work. In a software project, remaining work can be such tasks as user training documentation and installation manuals. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Showing dependencies of one task on others is not a characteristic of an agile plan. Since in agile we focus on creating a pull system rather than push system and we start with a top level plan first.

Principle of last responsible moment

In agile we do things at last responsible moment. The stories should have details and acceptance criteria attached before they get developed not before they get estimated.

– Traditional project management

Definition of business objectives occurs during the initiating phase in a traditional project management effort. [Manifesto for Agile Software Development. Agile Alliance.]

– Agile and traditional project management

The agile and traditional project management methods share closing as a phase name. Closing occurs as the last phase in both methods. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Value chain

Collaboration, responding to change, working software and individuals and interactions are on the higher side of the customer value chain. Processes and tools, comprehensive documentation, contract negotiation and following a plan are on the lower side of the customer value chain.

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

Assessing and incorporating community and stakeholder values

The following are community values of the PMI agile community of practice community charter: Vision, Servant Leadership, Trust, Collaboration, Honesty, Learning, Courage, Openness, Adaptability, Leading Change, Transparency [PMI Agile Community of Practice Community Charter. Project Management Institute.]

Brainstorming techniques

A successful brainstorming event should strive to consider the following points – Host the meeting in a neutral and comfortable environment – Have an engaging and experienced facilitator lead the event – Send participants an overview, with goals, schedule, and what ground rules, beforehand – Have a multi-disciplinary/diverse team to get a broader perspective – Delay any criticism that may stifle idea generation. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Brainstorming is a group activity held for the purpose of generating new ideas. The idea is that through collaboration, a team can generate more potentially valuable ideas than an individual, while at the same time forming a positive bonding experience for the team. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Building empowered teams

– Empowered teams

A team that is self-organizing and knows how to solve problems with minimal need for oversight.

Empowered teams – ones that are self-organizing and know how to solve problems with minimal management involvement – are a cornerstone of the agile methodology. This is the antithesis to the classic viewpoint of the traditional project manager who is seen as someone that controls all decisions and delegates tasks to a team with little feedback. An agile team must include all members and stakeholders to make decisions, and make decisions expediently. Because it is essential that the user/customer be involved with development, it is encouraged that the user/customer is closely integrated with the agile team with collocation/on-site support being ideal. An agile team feels empowered when it collectively assumes responsibility for the delivery of the product (i.e., taking ownership). [Coaching Agile Teams. Lyssa Adkins.]

Empowered teams – ones that are self-organizing and know how to solve problems with minimal management involvement – are a cornerstone of the agile methodology. An agile team feels empowered when it collectively assumes responsibility for the delivery of the product (i.e., taking ownership). [Coaching Agile Teams. Lyssa Adkins.]

Empowered teams take responsibility of the product and thus have a strong focus on delivering value.

Empowered teams need minimal management involvement and thus can focus on leading and delivering value instead of being lead

– Motivated team

Having a motivated team is essential for any project, regardless of whether it is agile or not. Motivated teams work together better, have strong productivity, and exceed expectations.

Some simple steps to increase motivation are :

1) spending quality time together; where team members get to know one another on a personal level to build a sense of community,

2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability, and

3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team.

[The Art of Agile Development. James Shore.]

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

– Leading

A common misconception in agile is that an agile team does not need a leader. In fact, all agile teams need a leader, but the way in which the leader leads is fundamentally different than the typical traditional project manager/project leader method. Some have theorized that this misconception stems from the desired ‘self-organizing’ quality of the agile team. And although the ‘self-organizing’ agile team is empowered to take ownership and responsibility of the product and make some decisions itself, it nevertheless requires a leader to help provide guidance, mentoring, coaching, problem solving, and decision making. Some key aspects required of an agile leader include: empowering team members to decide what standard agile practices and methods it will use; allowing the team to be self-organized and self-disciplined; empowering the team members to make decisions collaboratively with the customer; inspire the team to be innovative and explore new ideas and technology capabilities; be a champion of and articulate the product vision to team members so it will be motivated to accomplish the overall objective; remove any obstacles and solve any problems the team may face in its effort; communicate and endorse the values and principles of agile project management to stakeholders that may be unfamiliar with agile; ensure that all stakeholders, including business managers and developers, are collaborating effectively; and, be able to adapt the leadership style to the working environment to ensure that the agile values and principles are effectively upheld. [The Art of Agile Development. James Shore.]

Coaching and mentoring within teams

Coaching and mentoring within teams can be helpful for nascent agile teams and even for more experienced agile teams. Coaching and mentoring is the act of helping a person or team improve performance and achieve realistic goals. Because agile has a value of continuous improvement, coaching and mentoring is not solely for new or immature teams, but experienced ones too where coaching can help achieve higher levels of performance. The amount of coaching and mentoring an agile team needs is variable. Some newer teams will need a coach guiding the team nearly all the time while others may need a coach only for particularly challenging situations. A not uncommon scenario is to have a coach help the team collectively during sprint/iteration planning and then during the iteration help mentor individual team members. [Coaching Agile Teams. Lyssa Adkins.]

Communications management

– Effective communication

Effective communication is a cornerstone of agile. Communication is the act of transferring information among various parties. Communications management is a knowledge and skill area of agile that highlights this importance. PMI has several definitions regarding communications management and agile builds on top of these to add its own perspective: 1) Communications Planning: Determining the information and communication needs of the projects stakeholders 2) Information Distribution: Making needed information available to project stakeholders in a timely manner, 3) Performance Reporting: Collecting and distributing performance information. This includes status reporting, progress measurement, and forecasting, and 4) Managing Stakeholders: Managing communications to satisfy the requirements and resolve issues with project stakeholders. From an agile perspective: communication among the team is built into the process and facilitated through collocation, information radiators, daily stand-up meetings, retrospectives etc.; Although it is hoped that the product owner, customer, and user can be heavily involved with the project and also use these communication techniques, a plan for conveying information to stakeholders may be needed if this is not the case. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

– Documentation

Agile values working software more than comprehensive documentation but this doesn’t mean no documentation at all. Documentation should be written just in time and just enough.

Delivering comprehensive documentation will not deliver business value without working software. Historically, in software development, it’s been a priority to exhaustively document everything: requirements, design, test suites, correct usage, and so on. But that’s expensive; so expensive that often the software itself suffers from the effort devoted to documentation. So we don’t write documentation just because; we write documentation rather we do it when it has value and is required.

Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)

There are several feedback techniques – techniques that facilitate constructive criticism to improve product value and quality – built into the agile process. In the classic definition, feedback is a dynamic process where past information influences the behavior of the same process in the future. Agile feedback techniques include prototyping, simulation, demonstration, evaluations, pair programming, unit testing, continuous integration, daily stand-up meetings, sprint planning. Because agile prides itself on a transparent and collaborative environment, feedback is essentially ubiquitous. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Incremental delivery

A cornerstone of Agile development is ‘incremental delivery.’ Incremental delivery is the frequent delivery of working products, which are successively improved, to a customer for immediate feedback and acceptance. Typically, a product is delivered at the end of each sprint or iteration for demonstration and feedback. In this feedback technique, a customer can review the product and provide updated requirements. Changed/updated/refined requirements are welcomed in the agile process to ensure the customer receives a valuable and quality product. A sprint or iteration typically lasts from two to four weeks and at the end a new and improved product is delivered, incrementally. [The Art of Agile Development. James Shore.]

Knowledge sharing

In agile, effective ‘knowledge sharing’ is a critical factor for success. It involves the near real time communication of key information among all team members and stakeholders. To promote knowledge sharing, agile uses standard practices built into its process, such as using generalized specialists/cross functional teams, self-organizing and self-disciplined teams, collocation, daily stand-up meetings, iteration/sprint planning, release planning, pair programming and pair rotation, project retrospectives/reflection, and on-site customer support. And, of course, the sixth principle of Agile is  » The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. » In this sense, Agile prefers and encourages collocation for all stakeholders and team members for the simple fact that face-to-face conversation is the best method of communication and, in turn, effective knowledge sharing. [Becoming Agile:… in an imperfect world. Greg Smith, Ahmed Sidky.]

Leadership tools and techniques

Team is responsible for creating and enforcing the ground rules, scrum master should ensure that team does it.

Prioritization

The relative ordering of user stories with respect to value and risk.

An agile team must always face the prioritization of product features in its product backlog. From release planning to iteration planning, an agile team must prioritize the user stories/features of its product to ensure that high-quality and high-value features are developed first to help facilitate an optimized and early return on investment (ROI). An agile team typically prioritizes requirements or user stories/features in terms of relative value and risk; value is defined by the customer (i.e., customer-value prioritization). Two common methods to prioritize product features are: MoSCoW and Kano. The MoSCoW method categorizes features into ‘Must have,’ ‘Should have,’ ‘Could have,’ and ‘Would have’ features. The Kano method categorizes features into ‘Must haves (threshold),’ ‘Dissatisfiers,’ ‘Satisfiers,’ and ‘Delighters.’ Must haves are features that are requisite. Dissatisfiers are features that adversely impact perceived value and should be eliminated. ‘Satisfiers’ are features that increase perceived value linearly, where the more you add the more the customer is pleased, but are not required, and ‘Delighters’ are features that increase perceived value exponentially to please the customer. To prioritize features based on risk, a risk-to-value matrix can be used. A risk-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high risk. User stories are assigned to one of the four categories/quadrants: low-value, low-risk; low-value, high-risk; high-value, low-risk; high-value, high-risk. A cost-to-value matrix can also be made in this manner. All prioritization in agile is ‘relative,’ meaning that the priority of one user story is relative to other user stories and not prioritized on a fixed scale. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

In iteration planning, an agile team, collaboratively with the customer, chooses user stories to include for development. Although the user stories are prioritized in the product backlog initially during release planning, an agile team and customer should review prioritization based on progressive elaboration (i.e., gained knowledge and perspective). Prioritization is often based on value and risk and can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices. An agile team performs decomposition to subdivide user stories into more manageable tasks so that it may estimate task time. Tasks for an iteration may also be prioritized based on value, similar to how user stories are prioritized. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

The relative ordering of user stories with respect to value and risk :

– Cost-to-value matrix

To prioritize features based on cost, a cost-to-value matrix can be used. A cost-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high cost User stories are assigned to one of the four categories/quadrants: low-value, low-cost; low-value, high-cost; high-value, low-cost; high-value, high-cost. All prioritization in agile is ‘relative,’ meaning that the priority of one user story is relative to other user stories and not prioritized on a fixed scale. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– Risk-to-value matrix

To prioritize features based on risk, a risk-to-value matrix can be used. A risk-to-value matrix has four quadrants, with the horizontal axis having low and high value, and the vertical axis having low and high risk. User stories are assigned to one of the four categories/quadrants: low-value, low-risk; low-value, high-risk; high-value, low-risk; high-value, high-risk. A cost-to-value matrix can also be made in this manner. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– Kano

The Kano method categorizes features into ‘Must haves (threshold),’ ‘Dissatisfiers,’ ‘Satisfiers,’ and ‘Delighters.’ Must haves are features that are requisite. Dissatisfiers are features that adversely impact perceived value and should be eliminated. ‘Satisfiers’ are features that increase perceived value linearly, where the more you add the more the customer is pleased, but are not required, and ‘Delighters’ are features that increase perceived value exponentially to please the customer. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– MoSCoW

The MoSCoW method categorizes features into ‘Must have,’ ‘Should have,’ ‘Could have,’ and ‘Would have’ features. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Problem-solving strategies, tools, and techniques

Literally thousands of decisions are made in the course of a project. Many of these decisions are made in response to problems that inevitably arise and confront the agile team. Therefore it is essential that an agile team is properly versed in problem-solving strategies, tools, and techniques. Some common problem-solving techniques include: ask it loud; revisit the problem; 5Y; sunk cost fallacy; devil’s advocate; be kind, rewind; asking probing questions; and reflective/active listening. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

– 5 Y

Five (5) Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem

– Common problem-solving techniques
Ask it loud
Revisit the problem
5Y
Sunk cost fallacy
Devil’s advocate
Be kind
Rewind
Asking probing questions
Reflective/active listening

Project and quality standards for Agile projects

– Agile project management

Key characteristics of agile project management include: continuous improvement, cross-functional teams, short iterations, an incremental approach, and business priorities and customer value. [The Art of Agile Development. James Shore.]

– Agile triangle

The agile triangle includes value, quality, and constraints as its parameters. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

 – Agile iron triangle

The agile iron triangle includes cost, scope, and schedule as its parameters. Constraints is a parameter included in the agile triangle, not

The agile iron triangle. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Agile project management model

Jim Highsmith’s agile project management model consists of the following five phases: Envisioning, speculating, exploring, adapting, and closing. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Agile project management phases

The agile project management phases, in sequence, are: Envisioning, speculating, exploring, adapting, closing. [Manifesto for Agile Software Development. Agile Alliance.]

– Envisionning

The focus in the envisioning phase is on project vision, scope (and requirements), project schedule, and assembling a project team. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Speculating

The focus in the speculation phase is on estimating iteration and release plans, defining feature breakdown, developing a rough project plan, considering project risk and risk mitigation strategies, and estimating project costs. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Exploring

When conducting the exploring phase, project leaders assist developers by removing any obstacles or constraints that my impeded progress, and managing interaction with product owners, customers, and other stakeholders. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

In the exploring phase, the agile team focuses on designing, building, and testing product features. This occurs within useful increments to the customer. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Adapting

In the adapting phase, the agile team encourages feedback of the latest deliverable of an iteration. From the feedback, the team adapts product features and plans for the subsequent iteration. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Closing

In the closing phase, the agile team completes all remaining project work. In a software project, remaining work can be such tasks as user training documentation and installation manuals. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Works
Completing remaining project work
Authoring user documentation
Authoring product release instructions

– Agile development process

The agile development process has multiple iterations that focus on specific product features, encourages heavy customer feedback, and is adaptive to changing customer requirements. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

– Iteration

A cornerstone of Agile development is ‘incremental delivery.’ Incremental delivery is the frequent delivery of working products, which are successively improved, to a customer for immediate feedback and acceptance. Typically, a product is delivered at the end of each sprint or iteration for demonstration and feedback. In this feedback technique, a customer can review the product and provide updated requirements. Changed/updated/refined requirements are welcomed in the agile process to ensure the customer receives a valuable and quality product. A sprint or iteration typically lasts from two to four weeks and at the end a new and improved product is delivered, incrementally. [The Art of Agile Development. James Shore.]

– Project and quality standards

Refined over time.

All agile efforts have project and quality standards that the team defines collaboratively at the beginning of an effort and refines collaboratively throughout the effort. Project and quality standards help an agile team with team cohesion and provide a structure, albeit one that can adapt as the project evolves, to promote a self-disciplined environment. There is no ‘one size fits all’ standards definition in agile; because every project is different, it has been shown that the team should define which project and quality standards it should hold itself against and strive to conform to those standards while also being open to adapting those standards throughout the project to optimize performance and delivered value. Project standards can range from where the daily stand-up meeting is located and how long each participant has to share his or her progress and challenges to highly specific software coding styles, methods for test-driven development, and what the team’s definition of ‘done-done’ means. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

– Traditional project management phases

The traditional project management phases are typically introduced in the following sequence: Initiating, planning, executing, monitoring and controlling, and closing. It is important to note that monitoring and controlling happen concurrently and throughout the project life-cycle with other phases. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Stakeholder management

Stakeholder management is a growing topic area within strategic management that brings awareness to the importance of managing stakeholders (i.e., facilitating active participation of stakeholders and fostering a strong collaborative environment) for a project’s success.

Stakeholder management is typically defined in the context of guiding principles and values.

R. E. Freeman’s ‘Managing for Stakeholders’ includes 10 principles :

1) Stakeholder interests need to go together over time.

2) We need a philosophy of volunteerism – to engage stakeholders and manage relationships ourselves rather than leave it to government.

3) We need to find solutions to issues that satisfy multiple stakeholders simultaneously.

4) Everything that we do serves stakeholders. We never trade off the interests of one versus the other continuously over time.

5) We act with purpose that fulfills our commitment to stakeholders. We act with aspiration towards fulfilling our dreams and theirs.

6) We need intensive communication and dialogue with stakeholders – not just those who are friendly.

7)Stakeholders consist of real people with names and faces and children. They are complex.

8)We need to generalize the marketing approach.

9) We engage with both primary and secondary stakeholders. 1

0) We constantly monitor and redesign processes to make them better serve our stakeholders. Because stakeholder involvement is critical for the success of a project, where projects without active participation from stakeholders are prone to failure, stakeholder management should be a topic that every agile team knows well.

[The Art of Agile Development. James Shore.]

Team motivation

Having a motivated team is essential for any project, regardless of whether it is agile or not. Motivated teams work together better, have strong productivity, and exceed expectations. Some simple steps to increase motivation are 1) spending quality time together; where team members get to know one another on a personal level to build a sense of community, 2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability, and 3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team. [The Art of Agile Development. James Shore.]

– Simple steps to increase motivation :

1) spending quality time together; where team members get to know one another on a personal level to build a sense of community

2) providing feedback, mentoring and coaching; where team members are congratulated and thanked on jobs well done and also mentored or coached to improve in skill and capability

3) empowerment; where the team is empowered to make many key decisions which, along the way, builds trust and shows that leadership believes in the capabilities of the team

Time, budget, and cost estimation

Time, budget, and cost estimation is an important knowledge and skill area of agile. According to Highsmith, the nature of the agile method, whereby it welcomes changing scope, means that it lends itself well to fixed budgets and a fixed schedule because changing scope makes it difficult to estimate a total cost. Generally speaking, the budget and schedule constraints are known but before a project will commence there needs to be an agreed upon set of base product functionality defined in an initiation phase; fixing scope reduces an agile team’s innovative tendency to provide improved value. For companies that are familiar with fixed-price contracts, where requirements are agreed upon before contract closing, adopting agile can be a weary initial venture. Instead, other contract vehicle types are recommended for agile efforts. These include: a general service contract for the initiation phase and separate fixed-price contracts for iterations or user stories; time-and-material contracts; not-to-exceed with fixed-fee contracts; and, incentive contracts (e.g., fixed price with incentive; cost-reimbursable with award fee). [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Best contracts :

– A general service contract for the initiation phase

– And separate fixed-price contracts for iterations or user stories

– Time-and-material contracts

– Not-to-exceed with fixed-fee contracts

– Incentive contracts (Cost-reimbursable with award fee, Fixed-price with incentive)

Value-based decomposition and prioritization

In iteration planning, an agile team, collaboratively with the customer, chooses user stories to include for development. Although the user stories are prioritized in the product backlog initially during release planning, an agile team and customer should review prioritization based on progressive elaboration (i.e., gained knowledge and perspective). Prioritization is often based on value and risk and can be performed using the MoSCoW or Kano method and through the use of risk-to-value and cost-to-value matrices. An agile team performs decomposition to subdivide user stories into more manageable tasks so that it may estimate task time. Tasks for an iteration may also be prioritized based on value, similar to how user stories are prioritized. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

 

Agile and the value stream analysis

 Value stream analysis is described in :

– Value stream mapping

– Waste and WIDETOM

– Business value delivered chart

Value stream mapping

The value stream map is a Lean tool that practitioners use to analyse the value stream.

Value stream mapping is a lean manufacturing analysis technique adopted by agile. A value stream map may be used to analyze the flow of information or materials from origin to destination to identify areas of waste. The identified areas of waste are opportunities for process improvement. Waste can take many forms and can be remembered using the pneumonic device WIDETOM. W – waiting; I – inventory; D – defects; E – extra processing; T – transportation; O – overproduction; M – Motion. A value stream map is typically mapped or charted collaboratively with a team so it may define and view the entire process together, pinpointing areas of waste within the process. Processes that add value (processing of a part or feature) are generally referred to as « value-added » and processes that do not (e.g., waiting for a part to arrive) are generally referred to as « non value-added. » Generally speaking, one wants to reduce, to the largest extent possible, the non value-added time (i.e., areas of waste). [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– Steps
1.Identify product / service to improve
2.Create as-is value stream map
3.Identify delays, waste, and constraints
4.Create to-be value stream map
5.Develop roadmap to optimized state
6.Revisit the process in the future

Create a value stream map of the current process, identifying steps, queues, delays, and information flows.

Waste and WIDETOM

Waste can take many forms and can be remembered using the pneumonic device WIDETOM (W – waiting; I – inventory; D – defects; E – extra processing; T – transportation; O – over-production; M – Motion).

WIDETOM :

       W – waiting

I – inventory

D – defects

E – extra processing

T – transportation

O – over-production

M – Motion

Business value delivered chart

The entire enterprise (business, management, and development teams) needs the line of sight to velocity (points/time) dashboard-type view of work management which in other terms is a business value delivered chart.

 

Agile and the value based prioritization

Value based prioritization is based on :

– Compliance

– Customer valued prioritization

– ROI

– IRR

– PV

– NPV

– IRR and NPV

– Minimum marketable feature (MMF)

– Relative prioritization/ranking

– Value

Compliance

Compliance is the act of being in alignment with guidelines, regulations and/or legislation.

Customer valued prioritization

Customer-value prioritization is a method for relative prioritization of product features based on customer-value for ordering the product backlog. When ordering the product backlog, it is also important to consider other aspects (e.g., associated risk, dependencies, etc.,) of features. [The Art of Agile Development. James Shore.]

  ROI

Return on Investment (ROI): A metric used to evaluate the efficiency of an investment or to compare efficiency among a number of investments. To calculate ROI, the return of an investment (i.e., the gain minus the cost) is divided by the cost of the investment. The result is usually expressed as a percentage and sometimes a ratio. The product owner is often said to be responsible for the ROI. [Agile Estimating and Planning. Mike Cohn.]

Select project with biggest ROI.

ROI = (Benefit – Cost)/Cost

One of the key responsibilities of the product owner is the return on investment

IRR

The internal rate of return (IRR) is a financial metric used to measure and compare the profitability of investments. The IRR is the « rate » that makes the net present value of all cash flows from a particular investment equal to zero. Unlike NPV which is a dollar amount (i.e., a magnitude) value, the IRR is a rate (i.e., a percentage). Often times, the IRR is compared against a threshold rate value to determine if the investment is a suitable risk worth implementing. For example, you might calculate an IRR to be 13% for an investment while a comparative market rate is 2%. The IRR being larger than the comparative market rate, would indicate the investment is worth pursuing. [Agile Estimating and Planning. Mike Cohn.]

Select project with biggest IRR

PV

Present value

PV = Future Value / (1 + I)^n where I is the interest rate and n is the number of periods

NPV

Net present value (NPV)

Net Present Value: A metric used to analyze the profitability of an investment or project. NPV is the difference between the present value of cash inflows and the present value of cash outflows. NPV considers the likelihood of future cash inflows that an investment or project will yield. NPV is the sum of each cash inflow/outflow for the expected duration of the investment. Each cash inflow/outflow is discounted back to its present value (PV) (i.e.,, what the money is worth in terms of today’s value). NPV is the sum of all terms: NPV = Sum of [ Rt/(1 + i)^t ] where t = the time of the cash flow, i = the discount rate (the rate of return that could be earned on in the financial markets), and Rt = the net cash inflow or outflow. For example, consider the following two year period. The discount rate is 5% and the initial investment cost is $500. At the end of the first year, a $200 inflow is expected. At the end of the second year, a $1,000 is expected. NPV = – 500 + 200/(1.05)^1 + 1000/(1.05)^2 = ∼$597. If NPV is positive, it indicates that the investment will add value to the buyer’s portfolio. If NPV is negative, it will subtract value. If NPV is zero, it will neither add or subtract value. [Agile Estimating and Planning. Mike Cohn.]

Select project with biggest NPV

IRR and NPV

The internal rate of return (IRR) is a financial metric used to measure and compare the profitability of investments. The IRR is the « rate » that makes the net present value of all cash flows from a particular investment equal to zero. Unlike NPV which is a dollar amount (i.e., a magnitude) value, the IRR is a rate (i.e.,, a percentage). Often times, the IRR is compared against a threshold rate value to determine if the investment is a suitable risk worth implementing. For example, you might calculate an IRR to be 13% for an investment while a comparative market rate is 2%. The IRR being larger than the comparative market rate, would indicate the investment is worth pursuing. [Agile Estimating and Planning. Mike Cohn.]

NPV = 0 when NPV finding the IRR.

Minimum marketable feature (MMF)

A Minimal Marketable Feature (MMF) is a software feature or product feature that is both minimal and marketable. ‘Minimal’ taking the meaning of simple and small or not complex. ‘Marketable’ taking the meaning of having some value, whether it is revenue generating or cost saving, that can be marketed or sold. [The Art of Agile Development. James Shore.]

Relative prioritization/ranking

Relative ranking/prioritization involves ordering a list of items (e.g., user stories, epics, tasks, defects, etc.,) based on a team-defined definition of priority. [The Art of Agile Development. James Shore.]

Value, cost, and risk are key elements to consider when prioritizing user stories. [Agile Estimating and Planning. Mike Cohn.]

Value

– Pareto

The pareto rule stipulates that 80% of value derives from 20% of the work. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

–  Backlog

The product backlog helps both the team and the product owner understand the priorities required to deliver business value.

Agile and the soft skills negotiation

Key soft skills negotiation qualities for the effective implementation and practice of agile are: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership. [Coaching Agile Teams. Lyssa Adkins.]

– 6 keys
Emotional intelligence
Collaboration
Adaptive leadership
Negotiation
Conflict resolution
Servant leadership

6 keys of soft skills negotiation

– Emotional intelligence

– Collaboration

– Adaptive leadership

– Negotiation

– Conflict resolution

– Servant leadership

Emotional intelligence

Having a high emotional intelligence means self-awareness, control over your own emotions, and being attentive to other team members’ emotions. A high emotional intelligence allows team members to collaborate effectively. [Coaching Agile Teams. Lyssa Adkins.]

Higgs & Dulewicz (1999) defines emotional intelligence using seven components :

1) Self-awareness,

2) Emotional resilience,

3) Motivation,

4) Interpersonal sensitivity,

5) Influence,

6) Intuitiveness, and

7) Conscientiousness.

[Coaching Agile Teams. Lyssa Adkins.]

Collaboration

Collaboration is a key soft skill negotiation skill. It involves working in groups to create ideas, solve problems, and produce solutions. [Coaching Agile Teams. Lyssa Adkins.]

Pair programming is an effective method for improving team collaboration. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Adaptive leadership

Highsmith defines adaptive leadership as two dimensional: Being agile and doing agile. Being agile includes focusing on cornerstones of agile project management, like incremental delivery, continuous integration, and adapting to changing requirements. Doing agile includes several activities that an agile leader must do: do less; speed-to-value, quality, and engage and inspire. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Adaptive leadership :

– Being agile

Being agile includes focusing on cornerstones of agile project management, like incremental delivery, continuous integration, and adapting to changing requirements.

– Doing agile

Doing agile includes several activities that an agile leader must do: do less; speed-to-value, quality, and engage and inspire.

Negotiation

Agreement found through discussion.

Key soft skills negotiation qualities for the effective implementation and practice of agile are: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership. [Coaching Agile Teams. Lyssa Adkins.]

Negotiation is a key soft skill negotiation skill. It involves discussion or conversation to work towards a common understanding between two parties. [Coaching Agile Teams. Lyssa Adkins.]

 

Conflict resolution

Conflicts are unavoidable in the project environment.Conflict resolution must not focus on personalities and past events. The people who are in conflict are first responsible for resolving it.

Conflict resolution is a key soft skill negotiation skill. It involves applying proper leadership techniques to resolve and diffuse any conflict between team members or other stakeholders. [Coaching Agile Teams. Lyssa Adkins.]

 

Servant leadership

Servant leadership has its roots with an essay written in 1970 by Robert K Greenleaf. Greenleaf defined servant leaders as humble stewards devoted to their company and work to serve their peers, teams, and customers. In a self-organizing team, a servant leader, as Greenleaf defined it, is ideal as the team leader is an enabler, listening to the agile team’s needs, removing obstacles, and providing tools or other support to promote high productivity. [Coaching Agile Teams. Lyssa Adkins.]

Servant leader is an expected leadership style from Scrum master.

In high performance teams, leaders manage the principles and principles manage the teams. [Becoming Agile: …in an imperfect world. Greg Smith, Ahmed Sidky.]

Agile and risk management

 Agile risk management :

– Risks

– 5 core risks areas

– Risk audit

– Risk contingency

– Risk mitigation

– Risk monitoring

– Risk-adjusted backlog

– Risk-based burnup chart

– Risk burn down graphs

– Risk–based spike

Risks

The agile methodology generally deals with qualitative risks. NOT quantitative. [The Art of Agile Development. James Shore.]

Agile team follows Qualitative Risk analysis.

Quantitative risk analysis usually involves calculation of risk impact in monetary terms like Expected Monitory Value.

Whole team is responsible for managing risk. This must have made you wonder then how come Project manager role. It is important here to note that here we are not talking about agile and XP does recognize the role of Project Manager. The overall risk management responsibility can be assigned to Project Manager.

5 core risks areas

The five core risk areas include: productivity variation (difference between planned and actual performance); scope creep (considerable additional requirements beyond initial agreement); specification breakdown (lack of stakeholder consensus on requirements); intrinsic schedule flaw (poor estimates of task durations), personnel loss (the loss of human resources). [The Software Project Manager’s Bridge to Agility. Michele Sliger, Stacia Broderick.]

– 5 core risks areas
Productivity variation
Scope creep
Specification breakdown
Intrinsic schedule flaw
Personnel loss

Risk audit

A risk audit is typically performed in the iteration review after each iteration. [The Art of Agile Development. James Shore.]

Risk contingency

A contingency activity is an activity ready for implementation to reduce risk impact should a risk occur. [The Art of Agile Development. James Shore.]

Team is keeping some contingency reserve to take care of unexpected tasks it falls in Contain. In contain, we plan contingency reserve to take care of risk.

Risk mitigation

Generally, risk mitigation is thought of as the reduction of the impact whether or not the risk occurs. [The Art of Agile Development. James Shore.]

Risk monitoring

Risk is continuously monitored on an agile project through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives. [The Art of Agile Development. James Shore.]

Through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives. In other words, risk is monitored and controlled throughout an agile project and in many different ways. [The Art of Agile Development. James Shore.]

Risk-adjusted backlog

A risk-adjusted backlog is a product backlog organized by taking into account risk. Risk can be estimated as the product of severity/consequence and likelihood. User stories can also be positioned on a risk-to-value matrix to help prioritize them in the backlog. The risk-to-value matrix is a chart with four quadrants. Along the horizontal axis is value in ascending order. Along the vertical axis is risk in ascending order. A user story that is high risk and high value is located in the top-right corner. A user story that is low risk and high value is located in the lower-right corner. A user story that is low risk and high value is located in the lower-right corner. A user story that is low risk and low value is located in the lower-left corner. Typically a team will prioritize high-value, low-risk user stories first, followed by high-value, high-risk user stories, followed by low-value, low-risk user stories, followed by low-value, high-risk user stories. [The Art of Agile Development. James Shore.]

– New identified risk

Bring the newly identified risk to the team’s attention and to discuss its impact. [The Art of Agile Development. James Shore.] [Risk management]

Risk-based burnup chart

A risk-based burnup chart tracks targeted and actual product delivery progress and also includes estimates of how likely the team is to achieve targeted value adjusted for risk. Typically, risk is shown as three different levels: best-case; most likely; and worst-case. For example, if you have a 10 iteration project and the team’s current velocity is 10 story points, you can portray the chance of completing 100 story points (most likely case), the chance of completing 80 story points (worst-case), and the chance of completing 120 story points (best-case). In this way, the stakeholders get a feel for the range of risk. [The Art of Agile Development. James Shore.]

Risk burn down graphs

A project manager may use a burndown chart and a team’s velocity to make sure the team is not under or over committing to an iteration. A sustainable pace of development is an important facet of agile project planning and risk management. [The Art of Agile Development. James Shore.]

A risk burndown chart is a risk management technique used to track project risk over time. It allows stakeholders to quickly review project risk management performance (e.g., increasing, decreasing, and by how much) over time. Severity (a product of impact and probability) is charted along the vertical axis with time on the horizontal axis. Impact typically takes a value from 0 to 5 in increasing order of risk and probability/likelihood typically takes a value from 0 to 5 in increasing order of probability. In this example, the worst severity a risk could have is 25 (5 × 5 = 25) and the least harmful severity a risk could have is 0. The agile team and customer/product owner identifies its risks and assigns severity values in a risk register and tracks those values over time. Ideally, risk severity will decrease over time. [The Art of Agile Development. James Shore.]

Risk–based spike

Risked-based spike is a risk management technique and is often thought of as a task. A risked-based spike is a task used to gain knowledge in an area of uncertainty to reduce risk. For example, a development team may need to understand how migrating from Windows 7 to Windows 8 may impact the look and feel of the interface. Risked-based spikes typically are included in iteration planning directly before a the task that holds the uncertainty. [The Art of Agile Development. James Shore.]

Agile and the product quality

Product quality is defined by :

– Acceptance criteria

– Continuous integration

– Definition of done

– Escaped defects

– Project charter

– Test, test-driven development/test first development

– Frequent Verification and validation

Acceptance criteria

The acceptance criteria doesn’t be too vague (remember the T of INVEST for defining good user stories) and cannot be easily tested. [The Art of Agile Development. James Shore.]

Acceptance criteria is typically defined in tandem with user story definition during release planning; however, acceptance criteria can also be defined during iteration planning once a story has been picked for the iteration. The one steadfast rule is that acceptance criteria must be defined before development begins. Like agile planning, the definition of acceptance criteria is constantly evolving as the conversation with the product owner matures. [The Art of Agile Development. James Shore.]

During release planning, acceptance criteria are typically recorded on the backs of user story cards. Agile team testers will use this acceptance criteria in their verification tests. [The Art of Agile Development. James Shore.]

Acceptance test criteria should be written at the last responsible moment while velocity, product backlog and release length are essential input for release planning.

Continuous integration

The extreme programming (XP) principle of continuous integration is that code is integrated into the full code base as soon as it is built, tested, and completed. Once integrated, the code base and therefore the entire system is built and tested. Continuous integration is just one principle of XP that promotes rapid delivery of software and the early detection of integration defects. [The Art of Agile Development. James Shore.]

An XP project typically integrates code at least once per day. [The Art of Agile Development. James Shore.]

Being continuously integrated theoretically means having a working product ready to ship at any time. [The Art of Agile Development. James Shore.]

Definition of done

A cornerstone of the scrum framework in agile is to ‘always have a product that you could theoretically ship,’ it is important for the team and product owner to have a definition of ‘done’ or what criteria is necessary to consider user features or functionality in a state of finality. [Coaching Agile Teams. Lyssa Adkins.]

Because a cornerstone of the scrum framework in agile is to ‘always have a product that you could theoretically ship,’ it is important for the team and product owner to have a definition of ‘done’ or what criteria is necessary to consider user features or functionality in a state of finality. [Coaching Agile Teams. Lyssa Adkins.]

Escaped defects

An escaped defect is a software defect that is not found by the development or testing team and later found by an end-user. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Project charter

A project charter provides a brief overview of product functionality and serves as a guide for testers performing exploratory testing. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Test, test-driven development/test first development

Regular exploratory testing is encouraged to improve product quality. Typically, exploratory testing is performed on completed product software to test the system design for any bugs and to identify any new features that may add value to the customer. Exploratory testing should cover what a developer is unable to anticipate through the course of normal unit testing. A project charter is often used as a general overview of the product that exploratory testers use for testing guidance. [The Art of Agile Development. James Shore.]

The commit build process includes both unit and integration testing. [The Art of Agile Development. James Shore.]

In XP all testing are automated, the only manual testing, an XP team may perform is the Exploratory testing.

Testing and ATDD

Acceptance Test Driven Development (ATDD) is similar to Test-driven development (TDD) in that it requires programmers to create tests first before any product code. The tests in ATDD are aimed at confirming features/behaviors that the intended software will have. The iterative cycle of ATDD with its four steps can be remembered as the four Ds: 1) Discuss, 2) Distill, 3) Develop, and 4) Demo. 1) Discuss: The agile team and customer or business stakeholder discuss a user story in detail. Talking about the expected behaviors the user story should have and what it should not. 2) The development team takes those items learned from the discussion and distills them into tests that will verify and validate those behaviors. The distillation process is where the entire team should have a good understanding of what « done » (or completed) means for a user story. That is, what the acceptance criteria are. 3) After distillation, the team develops the test code and product code to implement the product features. 4) Once the product features have been developed, the team demonstrates them to the customer or business stakeholders for feedback. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– 4 steps in ATDD = 4 « D »s (DiDiDeDe)
1) Discuss
2) Distill
3) Develop
4) Demo

Acceptance test driven development. ATDD is the technique based on the test driven approach where the team discusses the acceptance criteria with the Business so that a detailed set of tests are designed in advance and is accepted by the business and stakeholders. The ATDD cycle starts from story discussions and then team distill this, followed by development and demo of item as mentioned in acceptance before marking this as DONE.

Testing and TDD

Test-driven development, or TDD, is an agile methodology that has software developers develop automated software tests before developing software that implements product features. This helps ensure quality as each bit of feature software is tested individually to remove bugs and improve performance before it is integrated with the final product. [The Art of Agile Development. James Shore.]

The TDD process has four basic steps :

1) Write a test,

2) Verify and validate the test,

3) Write product code and apply the test,

4) Refactor the product code.

An example may be that a user has to enter an age value. A good test is to make sure the user data entry is a positive number and not a different type of input, like a letter (i.e., write the test). The programmer would verify that entering a letter instead of a number would cause the program to cause an exception (i.e., v&v the test). The programmer would then write product code that takes user entry for the age value (i.e., write the product code). The programmer would then run the product code and enter correct age values and incorrect age values (i.e., apply the test). If the product code is successful, the programmer would refactor the product code to improve its design. Using these four steps iteratively ensures that programmers think about how a software program might fail first and to build product code that is holistically being tested. This helps produce high quality code.

[The Art of Agile Development. James Shore.]

– 4 steps in TDD = WVWR
1) Write a test
2) Verify and validate the test
3) Write product code and apply the test
4) Refactor the product code

By doing test first development we control Scope creep. By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding.

Frequent Verification and validation

Because each iteration typically produces a working product that is built and integrated and iterations are typically two to four weeks in length, there is frequent verification and validation to ensure product quality. Verification is the confirmation that a product performs as specified by a customer (e.g. as indicated by a user story) and validation is the confirmation that a product behaves as desired (i.e., meets the customer’s need). Sometimes a product may be built and integrated to specification – that is, it can be verified – but it does not meet the intent of the customer – that is, it cannot be validated. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Agile planning, monotoring and adapting

– Acceptance criteria

– Burn-down chart

– Burn-up chart

– Cumulative flow diagrams

– Definition of Done

– Iteration

– Kanban boards

– Lean manufacturing, lean-agile software development

– Process tailoring

– Reflection

– Reflexive improvement workshops

– Release planning

– Rolling wave plan or rolling look ahead plan

– Stakeholders

– Time boxing

– User Story

– WIP limits

Acceptance criteria

Acceptance criteria is typically defined in tandem with user story definition during release planning; however, acceptance criteria can also be defined during iteration planning once a story has been picked for the iteration. The one steadfast rule is that acceptance criteria must be defined before development begins. Like agile planning, the definition of acceptance criteria is constantly evolving as the conversation with the product owner matures. [The Art of Agile Development. James Shore.]

During release planning, acceptance criteria are typically recorded on the backs of user story cards. Agile team testers will use this acceptance criteria in their verification tests. [The Art of Agile Development. James Shore.]

Acceptance test criteria should be written at the last responsible moment, this is not the right time for writing them. While velocity, product backlog and release length are essential input for release planning.

The acceptance criteria doesn’t be too vague (remember the T of INVEST for defining good user stories) and cannot be easily tested. [The Art of Agile Development. James Shore.]

Burn-down chart

A burndown chart is a plot of work remaining to reach a given goal on the vertical axis, and time on the horizontal axis. Each point on the chart shows how much work was left to do at the end of that day (or week, month or other time period). Regular review of progress charts such as burndown charts or burn up charts for the project you are managing can immediately identify problems and allow you to control them early. Identifying problems early and highlighting corrective action you have taken will impress your clients and gain you their confidence and trust.

To read a burndown chart imagine an « ideal » line running diagonally from the top left to the bottom right corner. Some burndown chart may actually have this line indicated on the chart. The ideal line represents the required burndown to reach the goal, or the ideal position to be in at the end of each day. The actual burndown line can be compared against this line to provide a simple measure of the progress of the project. If the actual line is above the ideal line the project is behind schedule. If the actual line is below the ideal line the project is ahead of schedule. The distance above or below the line shows how much the project is ahead or behind.

The amount of work remaining in a burndown chart is typically estimated by the number of tasks remaining to be completed. This is due to simplicity and the smaller amount of volatility in the numbers compared to time estimates associated with the tasks.

Burndown charts are an important visual informational tool used by effective project managers. Burndown charts are particularly common in the agile and scrum project management methodology, where they are often used to understand and track the progress of a development sprint or release.

– Why use a burn-down chart ?

The popularity of burndown charts stems from their simplicity. It is a simple concept to see that the number of tasks must reach zero by a defined date. The human visual system also makes it very easy to extrapolate a trend from the data and see whether the goal will be reached in time or not. Thus burndown charts are useful aids to explain and demonstrate the progress of a project to anyone, regardless of whether they match your level of experience in project management. Therefore it is often a good idea to creating a burn down chart for use in presentations and demonstrations to clients and non-technical management.

Some managers also consider burndown charts to have a motivational value. Seeing the line creep ever closer to zero will encourage and motivate project participants, and clearly demonstrate that progress is being made. Personally, I believe that other charts of project progress such as burn up charts have the same motivational power, and so motivation should not be used as a reason for choosing a burndown chart over a different progress chart.

In summary, consider making a burndown chart if simplicity is your most important communication goal, and simplicity overrides the problems with a burndown chart.

– How to create a burn-down chart ?

Burn down charts are easy to create manually using pen and paper, or they can be created by entering the data into a spreadsheet program such as excel. Alternatively software tools such as Intelligent Reports make it trivially easy to create a burndown chart for your project by using data already contained in your project management system. There is no excuse for not making a burndown chart on a regular basis to review the progress of your project.

Burn-up chart

A burn up chart, or burnup chart, tracks progress towards a projects completion.

In the simplest form of burn up chart there are two lines on the chart:

– A total work line (the project scope line)

– A work completed line

The vertical axis is amount of work, and is measured in units customized to your own project. Some common units are number of tasks, estimated hours or story points (in agile project management methodologies).

The horizontal axis is time, usually measured in days.

At each day you can see the amount of work completed and the total amount of work. The distance between the two lines is thus the amount of work remaining. When the two lines meet, the project will be complete. This is a powerful measure of how close you are to completion of the project, similar to a burn down chart.

The advantage of a burn up chart over a burn down chart is the inclusion of the scope line. It clearly tracks when work has been added to or removed from the project. It also allows you to visualize a more realistic completion date for the project, by extending a trend line from the scope as well as the completion line. Where the two trend lines meet is the estimated time of completion.

The scope line allows you as a manager to easily spot where work is being added which will affect the completion date. Whether this work is being added by the client or the team, it is an important signal that the completion date may need to be moved in response. The scope line also tracks where work is being removed to meet a fixed deadline. Again this is important to know as it may impact the quality or functionality of the project, and is something that needs to be clearly discussed with the client and team.

Although a typical burn up chart only has two lines, other lines are sometimes included. Firstly an ‘ideal’ line may be included. This shows the completion necessary at each day to meet the deadline. You can then tell if the project is ahead of or behind schedule by whether it is above or below the ideal line, and the distance gives you an idea as to how far ahead or behind schedule it is. (The ideal line is usually based on the most recent available total scope for simplicity)

Another line that is sometimes included is the required burn up line. This line shows how much work must be completed to meet the deadline, given the current scope.

Lastly, several burn up charts can be superimposed on top of one another. This is typically done for multi stage projects, such as release versions or development sprints in a software project. The scope lines are cumulatively stacked, whilst the completed line is either combined for all releases, or only for the next release and previously completed releases on any given day. The advantage of this layout is that it is clear when work is being shifted from one sprint to the next, as opposed to being added to the total project scope.

More advanced, but also more complicated to read than a burn up chart is a cumulative flow diagram.

– Why use a burn-up chart ?

The goal of any chart is communication, a burn up chart clearly shows work completed and project scope. It is an effective tool for communicating to the project stakeholders and clients how the extra feature requests they are asking for will affect the deadline, and at the same time for reassuring them that good progress is being made. In a project where clients are adding a lot of work mid-project, a burndown chart will not be an accurate reflection of the project teams output, and could lead to performance questions from the client. A burn up chart can quickly make clients re-evaluate whether they really need that extra bell or whistle.

Unfortunately burn up charts are slightly more complex to interpret than burn down charts, so will often require some short explanation to people not familiar with them. However because of the extra information represented in a burn up chart, this explanation is usually more than worth the time, with the possible exception of large group situations.

– How to create a burn-up chart ?

A burn up chart can be created with many tools, from pen and paper to a spreadsheet program such as excel. The easiest way to create a burn up chart tracking a particular project is to use a project management tool with a good reporting system, such as Intelligent Reports for JIRA. Using reporting tools, burn up charts can be instantly or even automatically created using the data already tracked in your project management system. There is no excuse for not regularly reviewing progress charts such as burn up charts or burn down charts to check on the progress of your project, and take corrective action if any problems are discovered.

Burn-up vs burn-down chart

– Overview

Burn down and burn up charts are two types of charts that project managers use to track and communicate the progress of their projects.  A burn down chart shows how much work is remaining to be done in the project, whereas a burn up chart shows how much work has been completed, and the total amount of work.  These charts are particularly widely used in Agile and scrum software project management.

– Your goal ?

The primary determinant in whether to use a burn up or burn down chart is what you are trying to accomplish, your goal.  Are you presenting to clients for the continued survival of the project?  Are you trying to motivate your project team?  Are you simply trying to increase your own knowledge and understanding of what is happening in the project?  The answers to these questions will determine which chart to use.

– Simplicity vs information

Burn down charts are simple.  A single line racing towards zero as the project is completed.  Anyone can understand this chart, and it does not need an explanation.  However it can hide important information, for example the effects of scope change.

Scope change is when work is added to or removed from a project.  We are all familiar with scope change, the client suddenly demands extra features, or work is removed from a project to meet a deadline.  A burndown chart does not show this information as clearly as a burn up chart.

A burn up chart tracks completed work and total work with two separate lines, unlike a burn down chart which combines them into a single line.  The total work line communicates important information – is the project not yet complete because work is slow to be done, or too much new work is being added.  This information can be crucial in diagnosing and rectifying problems with a project.

– Presenting project progress on a regular basis

If you are presenting project progress to the same audience on a regular basis, for example weekly customer progress meetings, you are probably better off with a burn up chart.   It will allow you to easily show them you are making progress, even if they have been adding more work, or testing has revealed problems that are adding work to the project.

– Convincing customers to stabilize project scope

Scope creep is the enemy of every software project.  In the face of scope creep burn down charts start to look like little progress is being made.  However a burn up chart clearly makes the scope creep problem visible to the customer.  This may even help you to convince them to stop requesting changes and allow the project to complete.

– Fixed scope projects

There are certain limited circumstances in which a project may have a well defined fixed scope.  If a project is guaranteed to have fixed scope, the burn up chart communicates no more information than a burn down chart, so the simplicity of the burn down chart is preferable.

Cumulative flow diagrams

Like burnup charts, cumulative flow diagrams are information radiators that can track progress for agile projects. CFDs differ from traditional burnup charts because they convey total scope (not started, started, completed) of the entire backlog. Tracked items can be features, stories, tasks, or use cases. By tracking total scope, CFDs communicate absolute progress and give a proportional sense of project progress (e.g., On Day 14: 15% of features have been completed; 15% have been started; and, 70% have not been started). [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

A diagram used by Kanban is the cumulative flow diagram (CFD), which describes the overall flow through the Kanban system; it provides a measurement for every significant step in the workflow.

Definition of Done

The ‘done’ column holds tasks that have been completely developed, tested or verified, and integrated into the product and require no further attention. The ‘done’ column should not hold incomplete tasks, but ones that are truly completed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Definition of Done, the team makes it into congruence with the Product Owner, and definition of done is used to keep the meaning of ‘done’ consistent and unambiguous to all.

Iteration

– Change report

A change report is typically authored after a sprint has completed. [Agile Project Management with Scrum. Ken Schwaber.]

– Iteration planning

Iteration planning occurs before every iteration [The Art of Agile Development. James Shore.]

When a team performs iteration planning, it prioritizes features or user stories to develop in the forthcoming iteration by priority and velocity. The most valuable user stories are typically developed first and the team’s estimated velocity helps plan how many user stories or features should be developed in the iteration. [The Art of Agile Development. James Shore.]

When defining the length of iterations, the team should consider how it will deliver valuable chunks of product functionality, the definition and development of user stories, and the acceptance of user stories by customers. [Agile Estimating and Planning. Mike Cohn.]

During iteration planning, the team follows three steps to create an iteration backlog: 1) The team decomposes large or complex user stories into multiple, smaller stories, 2) The team breaks each user story into development tasks, and 3) The team estimates the task effort or duration, typically using ideal hours. [The Art of Agile Development. James Shore.]

– Iteration backlog

An agile team creates the iteration backlog during iteration planning [The Art of Agile Development. James Shore.]

– Iteration review

Iteration review is a step where stakeholders look at the progress by looking at working software.

– Progress

Tasks board : an agile team often uses a task board to monitor and control progress. A task board identifies tasks to be completed during an iteration and their progress. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– In Progress column

As a developer on the agile team, Greg is beginning development on a task. Greg is at the task board and must place the task card in the correct column of the task board to update everyone of its status. reg should place the task card in the ‘in progress’ column to signify that the task is currently being executed. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– Review

Because the product owner is responsible for ROI and has the most knowledge on what the complete objectives are for a product, the product owner should lead the sprint review. [Agile Project Management with Scrum. Ken Schwaber.]

– Tasks

The acronym SMART (specific, measurable, achievable, relevant, and time-boxed) helps the agile practitioner remember the characteristics of a well-defined task. S – Specific tasks are ones that clearly contribute to the development of a user story. It should not be vague. M – Measurable tasks are ones that the team and customer can verify. A – Achievable tasks are ones that developers may realistically implement and understand. R – Relevant tasks are ones that unequivocally add value to the user story. T – Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

                S – Specific tasks are ones that clearly contribute to the development of a user story. It should not be vague.

M – Measurable tasks are ones that the team and customer can verify.

A – Achievable tasks are ones that developers may realistically implement and understand.

R – Relevant tasks are ones that unequivocally add value to the user story.

T – Timeboxed tasks are ones that can have an estimate assigned of the amount of effort or time needed for development.

Agile team members should feel free to update incorrect task time estimates as soon as possible. Team members can use current iteration progress and accrued experience to come to a new task time estimate. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Kanban boards

Kanban, Japanese for billboard or signboard, is a scheduling system for just-in-time (JIT) production developed by Toyota in the 1940s and 1950s. It is a way of controlling and reducing inventory by using cards or signs to order (demand signal) requisite parts for a manufacturing process from other dependent systems (supply). Kanban has been adopted by agile to help control workflow. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Kanban is a just-in-time (JIT) scheduling system for inventory control. Production processes only execute if there is a demand signal for the part being processed. Carefully controlling inventory in this manner ensures that no machine is producing unnecessary/unordered parts. A machine will only send a demand signal if it has the capacity to perform the manufacturing immediately. Therefore, inventory (or WIP) will not backup or bottleneck at machines because the demand signal for inventory is highly controlled and based on processing speeds and absolute need. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Lean manufacturing, lean-agile software development

– Columns

All tasks must go through a testing or verification process to ensure quality is built into the development process. Typically, completed tasks are moved to the ‘Ready for testing’ column. Testing is then executed by the project testers and the customer. It is important to note that some tasks on the task board will not have specific verification or testing criteria. These tasks don’t go in the ‘Ready for testing’ column but still need to be verified and are often placed in a ‘To verify’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.] [Planning, monitoring, and adapting]

– To do

Tasks that have not yet started should be located in the ‘to do’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– In progress

– Ready for testing

Typically, completed tasks are moved to the ‘Ready for testing’ column. Testing is then executed by the project testers and the customer.

– To verify

It is important to note that some tasks on the task board will not have specific verification or testing criteria. These tasks don’t go in the ‘Ready for testing’ column but still need to be verified and are often placed in a ‘To verify’ column. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– Done

– WIP

Work in process = WIP

A lean manufacturing philosophy is to eliminate waste. One defined waste type in the lean philosophy is inventory, which is also referred to as work in process (WIP). WIP is material or parts that have started production but are not yet a finished or « done » product. Inventory is considered wasteful because it costs money to purchase, store, and maintain. One way of reducing inventory is to reduce the WIP at individual machines or servers by only moving as fast as your slowest machine or processor (the system bottleneck). Agile also strives to control its WIP through WIP limits by completing all features to a « done » state before beginning development of new features. One can think of an iteration or sprint as a process that can develop a certain amount of features. In this analogy, the WIP limit is equivalent to the sprint backlog. By maintaining a WIP limit equal to the sprint backlog, no features should be incomplete at the sprint review. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Like lean, agile efforts try to reduce WIP to a manageable and sustainable level. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

– WIP limit

A limit of how many WIPs can be in process at one time.

Process tailoring

Project trade-off matrix : the project trade-off matrix classifies the constraints of scope, schedule, and cost as fixed, flexible, or accept. [Agile Project Management: Creating Innovative Products – 2nd Edition. Jim Highsmith.]

Reflection

During reflection an agile team takes a break after completing an iteration to pause and contemplate about its performance. Topics include: lessons learned from successes and failures, such as programming methods that were highly efficient or inefficient; how to reinforce successful practices, such as new testing standard practices; how to discourage negative practices, like straying from team approved coding standards in order to make an iteration deadline. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Sprint retrospective are reflexive improvement workshops :

Reflective improvement workshops are a cornerstone of the Crystal methodology. While all agile methodologies incorporate reflection into their standard practices, Crystal terms the practice ‘reflective improvement workshops.’ [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Setting the stage for a retrospective means creating a safe environment that is open and honest. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Release planning

– Blitz planning

Blitz planning incorporates story dependencies and involves using cards to plan a project where timeline, tasks, and story dependencies are identified and considered. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

– Parking lot

An agile practitioner can use the project parking lot and story card layout to summarize a release plan. [Agile Estimating and Planning. Mike Cohn.]

– Release planning

Release planning helps the customer and agile team determine what should be developed during each project timeframe or phase, and when a product will ideally be ready for release. [The Art of Agile Development. James Shore.]

Planning for a release occurs during release planning. [The Art of Agile Development. James Shore.]

In release planning, the agile project manager discusses the product vision with the development team in detail. This ensures that the proper requirements, acceptance criteria, and priorities are established. [The Art of Agile Development. James Shore.]

For new product development projects, it’s good to plan at least 5 adaption points in a release, we analyze the performance at the end of iteration so we should have some minimum number of iterations which helps us in adapting based on the discovery we make at iteration end.

– User stories or features

User stories or features are first assigned to iterations during release planning. The user stories are features are then decomposed into tasks during iteration planning so that the tasks may be assigned to specific developers. To help manage planning and monitoring, a rule of thumb for estimating task duration is that each task should take approximately four hours to two days of development work. [The Art of Agile Development. James Shore.]

– Velocity

The team uses its velocity to pick the number of user stories to develop in the upcoming iteration. [The Art of Agile Development. James Shore.]

We calculate cost and time budget at release level based on estimated size and velocity. Product Owner is the one who owns the release plan.

Rolling wave plan or rolling look ahead plan

When using a rolling wave or rolling look ahead plan for complex projects, only work that is about to be completed for the next few iterations – where requirement details are better understood – are planned. The plan includes all interdependent agile project teams to ensure successful integration of tasks. [Agile Estimating and Planning. Mike Cohn.]

In large, complex projects, agile project leaders can facilitate iteration planning by using a rolling wave or rolling look ahead plan, which involves making plans for the next few iterations at a time. [Agile Estimating and Planning. Mike Cohn.]

Stakeholders

Stakeholders are a critical component of the agile framework where the latest increment of product functionality is demonstrated to the stakeholders for inspection, feedback, and adapting. [Agile Estimating and Planning. Mike Cohn.]

Time boxing

Timeboxing is a realistic estimate or expectation of how long an action, task, or event will take to perform. Some tasks cannot be performed in the initial timeboxed estimate and are good candidates for reevaluation and possibly further decomposition into more tasks. [The Art of Agile Development. James Shore.]

– Avantages
Establishes a WIP Limit
Forces Prioritization
Demonstrates Progress

– Scrum

In the agile framework scrum, sprint planning and sprint review meetings are often timeboxed at four hours. [The Art of Agile Development. James Shore.]

– Sprint planning, sprint review, sprint retrospective

                4 hours

User Story

User stories are prioritized based on customer value. Value is determined by return on investment, growth of team knowledge, and risk reduction. [The Art of Agile Development. James Shore.]

The team should meet with the customer to determine if and when the user story should be completed. [Agile Estimating and Planning. Mike Cohn.]

– 3 C

Ron Jeffries’ three Cs for user story definition are card, conversation, confirmation. [User Stories Applied: For Agile Software Development. Mike Cohn.]

– INVEST

Independent, negotiable, valuable, estimable, small, and testable

The acronym INVEST (independent, negotiable, valuable, estimable, small, and testable) helps the agile practitioner remember the characteristics of a good user story. I – Independent stories can be developed in any order and avoid dependencies which can make development more complex. N – Negotiable user stories mean that both the customer and developer should feel free to analyze and adapt a user story to meet customer needs. V – A valuable user story describes how the product feature will provide value to the customer. E – Estimable user stories are ones that developers can readily estimate the effort or duration required for developing them. S- Small user stories are ones that take about two to five days of work to implement. T – Testable user stories are ones that can be verified according to acceptance criteria to ensure value. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

I – Independent stories can be developed in any order and avoid dependencies which can make development more complex.

N – Negotiable user stories mean that both the customer and developer should feel free to analyze and adapt a user story to meet customer needs.

V – A valuable user story describes how the product feature will provide value to the customer.

E – Estimable user stories are ones that developers can readily estimate the effort or duration required for developing them.

S- Small user stories are ones that take about two to five days of work to implement.

T – Testable user stories are ones that can be verified according to acceptance criteria to ensure value.

– If a team has a velocity of 20 story points and there are 83 story points remaining in the backlog and excluding all other potential constraints like increased scope, how many iterations should it take for the project team to complete the remaining story points?

3/20=4.15. Round 4.15 up to 5. 5 iterations is the best answer. [Agile Estimating and Planning. Mike Cohn.]

– Story points

In general, story points can be considered as the cost of developing a user story, while value points can be considered as the benefit of developing a user story. [Agile Estimating and Planning. Mike Cohn.]

A 0 point user story is said to be of minimal effort for a development team. [Agile Estimating and Planning. Mike Cohn.]

WIP limits

– Work in process

A Kanban board shows work in process (WIP), which represents work started but not completed. Therefore, the WIP should be limited and carefully managed to maximize performance. More WIP does not equal more output; in fact, it is quite often the opposite. Also, WIP is any work that is in progress, regardless of what stage the work is at, so the answer options that limit it to work waiting for quality assurance or user acceptance are wrong.

Like lean, agile efforts try to reduce WIP to a manageable and sustainable level. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Agile metrics

– Cycle Time

– Earned Value Management (EVM)

– Progress

– Velocity

Cycle time

– Value and progress

Because value is delivered incrementally and iteratively through iterations, value and progress is typically measured at the end of each iteration. [The Art of Agile Development. James Shore.]

– Project burndown bar chart

If a bar extends below the horizontal axis on a project burndown bar chart, work has been added to the project indicating an increase in scope. [Agile Estimating and Planning. Mike Cohn.]

If the bottom of the bar on a product burndown bar chart is above the horizontal axis, it indicates that work has been removed from the project (scope reduction) since initial planning. [Agile Estimating and Planning. Mike Cohn.]

The top of a bar on a product burndown bar chart may lower from one iteration to the next because the team completed work in the previous iteration or the team re-estimated user story development effort. When the team completes planned work during the iteration the top of the bar chart is lowered. Additionally, the top of the bar chart may be lowered if the team re-estimates user stories and finds they are not as challenging as previously believed and therefore represent a smaller story point value. [Agile Estimating and Planning. Mike Cohn.]

– Source line of code reports (SLOC)

SLOC reports are an imperfect source to be used for productivity reports. [The Art of Agile Development. James Shore.]

EVM, earned value management for agile projects

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). [Agile Estimating and Planning. Mike Cohn.]

– BAC
Budget at completion

– CPI
Cost Performance Index (CPI)
CPI = EV / AC
< 1 is bad,  = 1 is good,  > 1 is good

– CV
Cost Variance (CV)
CV = EV – AC
< 0 is bad,  = 0 is good,  > 0 is good

– PV
Planned value

– SPI
Schedule Performance Index (SPI)
SPI = EV / PV
< 1 is bad,  = 1 is good,  > 1 is good

– SV
Schedule variance
SV = EV – PV
< 0 is bad,  = 0 is good , > 0 is good

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. [Agile Estimating and Planning. Mike Cohn.]

EVM or earned value management is a management technique used to evaluate project performance with respect to cost and schedule. EVM relies on other common financial metrics like Budget At Completion (BAC), Actual Cost (AC), Planned Value (PV), Earned Value (EV), Cost Variance (CV), Schedule Variance (SV), Cost Performance Index (CPI), and Schedule Performance Index (SPI). PV is the planned value of work at a given time in a project; you can calculate it by multiplying the BAC by the ratio of current week/scheduled weeks (e.g., 5 weeks into a 15 week $15,000 project = $5,000 PV). EV is value of work actually completed or earned (e.g., you have completed 50% of the project by week 5 of a 15 week $15,000 project = $7,500 EV). SPI = EV / PV. If SPI > 1, the project is ahead of schedule and if SPI < 1, the project is behind schedule. AC is the actual cost the project has incurred to date. [Agile Estimating and Planning. Mike Cohn.]

Progress

Of the options presented the best tool to show work in progress is a task board. The user story backlog shows what work is still remaining to be done on the project. The product roadmap shows when work is planned to be completed. Work breakdown structures are not commonly used on agile projects.

– Burnup chart.

A graph that shows the progress of work toward a goal line associated with a value on the vertical axis. As work is completed over time (the horizontal axis), the progress line moves up (burns up) to be nearer to the goal line.

Velocity

Velocity is a measure of the number of user story points or stories completed per iteration. An agile team can use its previous velocity values as a method of estimating how many user story points it may complete in the next iteration. [Agile Estimating and Planning. Mike Cohn.]

If a user story is not accepted by the product owner during a sprint review, the team should not mark the story as complete and collaborate with the product owner to determine if and when the user story should be completed. [Agile Estimating and Planning. Mike Cohn.]

Story points for partially completed stories are not included in the velocity metric. [Agile Estimating and Planning. Mike Cohn.]

Velocity alone is insufficient for comparing productivity among two or more agile teams. This is because no two teams share the same definition of a story point. [Agile Estimating and Planning. Mike Cohn.]

Agile communications

 Agile communications are described in the Agile Manifesto.

The Agile Manifesto developed by the Agile Alliance covers 4 values and 12 principles.

The four values are :

1) individuals and interactions over processes and tools,

2) working software over comprehensive documentation,

3) customer collaboration over contract negotiation, and

4) responding to change over following a plan.

The 12 principles are :

1) focusing on satisfying the customer,

2) welcoming change,

3) delivering working software frequently,

4) ensuring that business people and developers work together,

5) motivating the individuals involved in development,

6) using face-to-face communication whenever possible,

7) working software as the primary measure of progress,

8) maintaining a constant pace of development,

9) paying continuous attention to technical excellence and good design,

10) aiming for simplicity,

11) using self-organizing teams, and

12) regularly reflecting on how to become more effective.

[Manifesto for Agile Software Development. Agile Alliance.]

Agile communication tooling

– Empathy

– Face-to-face communication

– Leading

– Regular communication

– Environment

– Information radiator

– Osmotic communication

– No-collocated / distributed team

– Stand-up meeting

– Team space

Empathy

Customer-programmer empathy and programmer-tester empathy help generate team trust on an agile project. [The Art of Agile Development. James Shore.]

Face-to-face communication

An open, face-to-face communication culture is the best suited culture for an agile team. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Face-to-face communication enhances team collaboration. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Leading

As a team leader or agile project manager, you must facilitate communication between the development team and customer to ensure that requirements are understood and implemented correctly. One of the four Agile Manifesto values underscores customer collaboration. The team leader must facilitate this collaboration to deliver value. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Regular communication

An agile approach heavily emphasizes the need for direct customer involvement to ensure product quality and value. One way to promote customer engagement is to have regular communication between the customer and team. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Environment

A warm, welcoming environment that promotes effective communication, innovation, and motivated team members is an important aspect to consider when designing team space. Guidelines for a better agile team space include: collocation of team members; reduction of nonessential noise/distractions; dedicated whiteboard and wall space for information radiators; space for the daily stand-up meeting and other meetings; pairing workstations; and other pleasantries like plants and comfortable furniture. [Agile Retrospectives: Making Good Teams Great. Esther Derby, Diana Larsen, Ken Schwaber.]

Information radiator

An information radiator is a visual representation of project status data. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

An information radiator displays project status-related information, such as user story development status, burndown charts, and task boards. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

A visual representation or chart that shows project status regarding a tracked project-related metric.

An information radiator should be posted in a highly visible area that is easily accessible by the team and stakeholders. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Information radiators do not increase the efficiency of software developers. The use of information radiators on an agile project offer several advantages. They reduce lengthy communication, allow for all team members and stakeholders to review project status throughout a project, and reduce the need of other more time-consuming communication methods, like e-mails or memorandums. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

All successful projects, regardless of management philosophy, require project planning. The use of information radiators on an agile project offer several advantages. They reduce lengthy communication, allow for all team members and stakeholders to review project status throughout a project, and reduce the need of other more time-consuming communication methods, like e-mails or memorandums. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Information radiators improve team communication by reducing the amount of time spent explaining project status. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Typical information radiators on an agile project include: project burndown charts, task boards, burnup charts, and defect charts. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Information radiators should be updated whenever the posted data has changed to keep all team members and stakeholders up to date. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

– Typical information radiators
Project burndown charts
Task boards
Burnup charts
Defect charts

Osmotic communication

Osmotic communication is a concept of communication where information is shared between collocated team members unconsciously. By sharing the same work environment, team members are exposed to the same environmental sounds and other environmental input and unconsciously share a common framework that improves communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Osmotic communication includes picking up visual cues, like body language. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Osmotic communication helps ensure the natural flow of questions, ideas, and information sharing among the agile project team. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

A core principle of the Crystal methodology is osmotic communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

No-collocated / distributed team

Video conferencing, e-mail and instant messaging are technologies that can provide some level of communication in the absence of face-to-face communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Video conferencing and instant messaging are technologies that can provide some level of osmotic communication. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Stand-up meeting

A stand-up meeting is typically held daily and is often referred to as the daily stand-up meeting. [The Art of Agile Development. James Shore.]

The term « stand-up » originates from the fact that ALL team members are encouraged to stand during the meeting to promote meeting efficiency. The theory is that by physically standing no one will get comfortable enough to waste valuable time. [The Art of Agile Development. James Shore.]

In the scrum-based agile project management methodology, daily stand-up meetings are referred to as ‘scrums’ or ‘Daily scrum.’ [The Art of Agile Development. James Shore.]

In the scrum framework, daily stand-up meetings, or scrums, should last no longer than 15 minutes. Some scrum instances use stop watches to track time and use a ‘talking stick’ to help indicate whose sole turn it is to share pertinent information. [The Art of Agile Development. James Shore.]

In a daily stand-up meeting team members discuss current progress and any issues or impediments that are impacting progress. Each team member shares what he or she has achieved since the last meeting, what he or she will achieve before the next meeting, and what obstacles may prevent him or her from achieving progress. [The Art of Agile Development. James Shore.]

The key characteristics of a healthy stand-up meeting include: peer pressure – the team is dependent upon each other so expectations of peers drives progress; fine-grained coordination – the team should understand the necessity for focus and working dependently; fine focus – the team should understand the need for brevity in the stand-up meeting so the team can be productive; daily commitment – the team should understand the value of daily commitments to each other and uphold those commitments; identification of obstacles – the team collectively should be aware of each other’s obstacles so that the team collectively can try to resolve them. [The Art of Agile Development. James Shore.]

Fine-grained coordination, a fine focus, and daily commitment : issues that take longer than a few minutes to resolve in a daily stand-up meeting should be tabled and resolved between the appropriate parties after the daily stand-up meeting has concluded. This ensures that the meetings are brief and productive. [The Art of Agile Development. James Shore.]

The use of a stop watch is sometimes used in the daily stand-up meeting to ensure that the meeting is brief and productive. Typically, a stand-up meeting should last no longer than 15 minutes (i.e., a 15 minute timebox). [The Art of Agile Development. James Shore.]

A high-performance, self-organizing team should realize and correct the disruptive behavior. [Coaching Agile Teams. Lyssa Adkins.]

Team space

A high-performance, self-organizing team should realize and correct the disruptive behavior. [Coaching Agile Teams. Lyssa Adkins.]

Agile analysis and design

Agile modeling is describe in the Crystal development process

The Crystal development process is cyclical/iterative, its primary components are chartering, delivery cycles, and project wrap-up.

 

Agile chartering

Chartering involves creating a project charter, which can last from a few days to a few weeks.

Chartering consists of four activities:

1) Building the core project team,

2) Pperforming an Exploratory 360° assessment,

3) Fine tuning the methodology,

4) Building the initial project plan.

[Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
In the XP framework, the best role for a customer in XP is to write well-defined user stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]

1) Building the core project team

2) Performing an Exploratory 360° assessment

The executive sponsor conducts the Exploratory 360° assessment to assess the business case of the project. Several dimensions are explored: business value, requirements, domain area, and technology impacts. Based on the results the team adjusts the Crystal methodology to the need or, in some cases, the project may be cancelled if serious issues are discovered. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

3) Fine tuning the methodology

4) Building the initial project plan

 

Examples of questions for the PMI-ACP exam :

– Question 1 :
In which agile project management methodology does chartering play a significant role?
A. TDD
B. Crystal
C. XP
D. FDD
– Answer 1 :

B – The Crystal development process is cyclical/iterative. Its primary components are chartering, delivery cycles, and project wrap-up. Chartering involves creating a project charter, which can last from a few days to a few weeks. Chartering consists of four activities: 1) Building the core project team, 2) performing an Exploratory 360° assessment, 3) fine tuning the methodology, and 4) building the initial project plan. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.] [Agile analysis and design]
– Question 2 :
What is the purpose of the Exploratory 360 assessment?
A. To define the core project team
B. To assess project soundness in terms of business value and feasibility
C. To conduct an introspective reflection on the team makeup
D. To define a project mission and vision
– Answer 2 :

B – The executive sponsor conducts the Exploratory 360° assessment to assess the business case of the project. Several dimensions are explored: business value, requirements, domain area, and technology impacts. Based on the results the team adjusts the Crystal methodology to the need or, in some cases, the project may be cancelled if serious issues are discovered. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.] [Agile analysis and design]

 

Personas

A persona is a notional user of the system under development. Being much more detailed than actors in use case modeling where generic user names are assigned (e.g., end user), personas try to elaborate on users with detailed descriptions to provide context to the developers. Some personas have such notional details as name, address, age, income, likes and dislikes, and other specific details. [User Stories Applied: For Agile Software Development. Mike Cohn.]

All details are important details

– Extrem character

They are some exceptional personas. We should identify them since it leads to identification of some of the important user stories which we may miss if we do not identify them.

 

Examples of questions for the PMI-ACP exam :

– Question 1 :

In agile modeling, what is a persona?

A. A made up personality used for facilitating the daily stand-up meeting

B. An assigned personality used in reflection workshops.

C. A notional user of the system under development.

D. A method to describe the customer’s personality for the day so the team may adapt to his or her feedback in the most effective way
– Answer 1 :

C – A persona is a notional user of the system under development. Being much more detailed than actors in use case modeling where generic user names are assigned (e.g., end user), personas try to elaborate on users with detailed descriptions to provide context to the developers. Some personas have such notional details as name, address, age, income, likes and dislikes, and other specific details. [User Stories Applied: For Agile Software Development. Mike Cohn.] [Agile analysis and design]

 

Product roadmap

A high level overview of the product requirements.

The product roadmap – owned by the product owner – serves as a high level overview of the product requirements. It is used as a tool for prioritizing features, organizing features into categories, and assigning rough time frames.

Creating a product roadmap has four basic steps :

1) Identify requirements (these will become part of the product backlog),

2) Organize requirements into categories or themes,

3) Estimate relative work effort (e.g., planning poker or affinity estimation) and prioritize (value), and

4) Estimate rough time frames (estimate velocity, sprint duration, and rough release dates).

[The Art of Agile Development. James Shore.]

 

– 4  basic steps

1) Identify requirements (these will become part of the product backlog)

2) Organize requirements into categories or themes

3) Estimate relative work effort (e.g., planning poker or affinity estimation) and prioritize (value)

4) Estimate rough time frames (estimate velocity, sprint duration, and rough release dates)

 

Continuous planning

Progressive elaboration is continuous planning with the expectation that project plans and details will change but become more refined as the project progresses. [Agile Estimating and Planning. Mike Cohn.]

 

Rolling wave planning

Waves or phases, only the next few iterations are planned in detail.

The iterations more distant are planned only at a high-level.

Rolling wave planning (or rolling look ahead planning) involves planning in waves or phases and is especially useful for large, complex projects. Only the next few iterations are planned in detail and iterations more distant are planned only at a high-level. [Agile Estimating and Planning. Mike Cohn.]

 

Prototypes

Prototypes are low cost, low risk methods to portray a design idea to a customer in order to obtain feedback before development. Although time consuming and having cost, prototypes can help save later costs that may occur if a design is not modeled beforehand to obtain feedback and fails to meet customer expectations. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

In the agile design process, prototypes help the customer understand current design state. Three common types of prototypes are HTML, paper (i.e., sketches), and wireframes. A wireframe is a sketch of a user interface, identifying its content, layout, functionality, is usually black and white, and excludes detailed pictures or graphics. A wireframe can be created on paper, whiteboards, or using software. [Agile Estimating and Planning. Mike Cohn.]

– HTML

HTML and other software based solutions are ideal for presenting prototypes to customers, especially when off site. Software based prototypes are dynamic, graphic capable, and portable. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]
– Wireframes

A wireframe is a sketch of a user interface, identifying its content, layout, functionality, is usually black and white, and excludes detailed pictures or graphics. A wireframe can be created on paper, whiteboards, or using software.

– Maquette
– Story maps
– Story map

In agile, the story map is essentially the project plan. It orders the user stories/product features into logical themes to serve as a plan for development. [User Stories Applied: For Agile Software Development. Mike Cohn.]

 

Themes

A theme, in the context of agile development, is a set of related user stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]

 

Product backlog

A list of the product features to be developed in a release.

The product backlog is a comprehensive list of all product features to be developed in an iteration. It is an evolving document and changes to adapt to customer requirements. As the project progresses, project features in the backlog become better defined as the customer understands product need more completely. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

 

Sprint backlog

A list of the product features to be developed in a sprint.

The sprint backlog is a list of product features or work items to be completed in a sprint. It is typically fixed for the sprint unless it is overcome by important customer requirements. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

 

User Stories

A user story is composed of the following three aspects :

1) A written description of the story;

2) Conversations about the story (think verbal, rather than written here); and,

3) Tests that convey when a story can be accepted or complete. [User Stories Applied: For Agile Software Development. Mike Cohn.]

– 3 aspects
1) A written description of the story
2) Conversations about the story (think verbal, rather than written here)
3) Tests that convey when a story can be accepted or complete

User stories include activities that have a  clear end point or exit criteria. [User Stories Applied: For Agile Software Development. Mike Cohn.]

The ideal development duration range for a user story is 2 to 5 days. [User Stories Applied: For Agile Software Development. Mike Cohn.]

 

Collaboration with customer

Because agile emphasizes customer collaboration, the team should simply collaborate with the customer to clarify the user story. [User Stories Applied: For Agile Software Development. Mike Cohn.]

 

Organization

Various grouping methods are used to organize user stories. Typical methods are: 1) Relation to a product feature (e.g., all user stories that interact with the database), 2) By logical sequence and dependency (e.g., Group 1 must be developed before Group 2 because of technological dependency), 3) By priority based on customer value. [User Stories Applied: For Agile Software Development. Mike Cohn.]

 

MoSCoW technique

The MoSCoW technique is commonly used in agile to prioritize user stories and create a story map.

The MoSCoW technique prioritizes user stories into the following groups in descending order of priority: M – Must have; S – Should have; C – Could have; W – Would have.

Must have items are those product features which are absolutely essential to develop.

Should have items are product features that are not essential but have significant business value.

Could have items are product features that would add some business value.

Would have items are product features that have marginal business value.

[User Stories Applied: For Agile Software Development. Mike Cohn.]

M – Must have

S – Should have

C – Could have

W – Would have

Agile estimation

– Affinity estimating

– Ideal time

– Ideal days

– Idle Time

– Elapsed Time

– Project buffer

– Project burndown chart

– Relative sizing/story points

– Local safety

– Parking lot chart

– Planning poker

– Product backlog

– Reference point user story

– Story points

– User story

– Revenue

– Velocity

– Wide band Delphi

– Planning poker

Affinity estimating

Affinity estimating is a method to predict the work effort, typically in story points, of developing a user story. It is particularly useful for large product backlogs. Although several methods exist, the basic affinity estimating model involves sizing user stories on a scale from small to large. The scale can be a Fibonacci sequence or t-shirt sizes and is typically taped to a wall in a large conference room. Participants then attach their user stories to the wall as estimates. It is often done in silence and has several iterations until the user stories have been estimated. [The Art of Agile Development. James Shore.]

The Fibonacci sequence begins with 0 and 1 and every successive number is the sum of the previous two numbers. Therefore the Fibonacci sequence begins 0, 1, 1, 2, 3, 5, 8, 13, etc. In planning poker, a 1 is removed because it is redundant. [Agile Estimating and Planning. Mike Cohn.]

When estimating an agile project, a top-down approach is typically used. This involves high-level estimation at first, followed by more detailed estimation. [Agile Estimating and Planning. Mike Cohn.]

Ideal time

Time spent exclusively on the task, with no interruptions and in a good work disposition.

The time we estimate it will take to complete a story uninterrupted (consider this an estimate of size).

Ideal days

Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days. Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the user story, relative to other user stories in the backlog. [Agile Estimating and Planning. Mike Cohn.]

The agile estimation technique of ideal days ignore, discount, or simplify delays, obstacles, non-working days, and the possibility that multiple developers may work on the user story.

Idle Time

Unproductive time on the part of employees or machines as a result of factors beyond their control. Idle time is the time associated with waiting, or when a piece of machinery is not being used but could be. Idle time could also be associated with computing, and in that case refers to processing time.

Elapsed Time

The actual amount of time it will take to complete the story.

Project buffer

A project buffer is extra time added to the end of a project to account for delays, obstacles, and other unforeseen issues to help predict an accurate completion date. A project buffer can be estimated using several methods.

Three commonly used methods are :

1) square root of the sum of squares method,

2) Critical chain project management method (CCPM),

3) halving the sum of most likely estimates.

The square root of the sum of squares method involves finding a local safety for all tasks, squaring all the local safeties, summing these squares, and then finding the square root of the sum.

The Critical chain project management method (CCPM) is the sum of half the local safeties of all tasks. The local safety is the difference between the 50% confidence estimate and the 90% confidence estimate.

The halving the sum of most likely estimates method involves adding all the most likely estimates and dividing by two. [Agile Estimating and Planning. Mike Cohn.]

The agile practitioner should follow several rules of thumb when estimating a project buffer:

1) Only use a buffer if the project has more than 10 user stories,

2) The square root of the sum of squares method has shown to provide the most accurate buffer,

3) the estimate buffer should be at least 20% of the total project duration,

4) In the absence of sufficient data. like worst case scenario estimates, you can use the halving of most likely estimates to estimate a project buffer. [Agile Estimating and Planning. Mike Cohn.]

Project burndown chart

A project burndown chart is an often used information radiator to show iteration progress. It charts two series: the actual work remaining and ideal/estimated work remaining. The vertical axis is the work unit (often story points or hours) and the horizontal axis is iteration duration (typically in number of days). The ideal/estimated work series is a straight, downward sloping line originating on the vertical axis at the value of work to be completed (e.g., 20 story points) and extending to the horizontal axis (i.e., 0 story points) on the last day of the iteration. The actual series is dependent upon the agile team’s productivity and the task complexity and is updated daily. The actual series is typically volatile and is not a straight line but ebbs and flows as the project team tackles the development process. [Agile Estimating and Planning. Mike Cohn.]

Relative sizing/story points

Agile teams typically use story points to estimate the relative size or effort of developing a user story [Agile Estimating and Planning. Mike Cohn.]

Agile teams should agree to one method of estimation, either story points or ideal days, as both use different units of measurement and can lead to confusion. [Agile Estimating and Planning. Mike Cohn.]

Both planning poker and affinity estimation are agile techniques used to size the work effort of developing user stories. [Agile Estimating and Planning. Mike Cohn.]

Instead of using story points, agile teams may estimate the relative sizes of user stories using ideal days. Ideal days represents the amount of days – uninterrupted by meetings, personal life, non-working days, or any other delays, obstacles or distractions – that it would take a single person to build, test, and release the user story, relative to other user stories in the backlog. [Agile Estimating and Planning. Mike Cohn.]

Local safety

The local safety is the difference between the 90% confidence estimate of task time and the 50% confidence estimate of task time. Remember that estimates for task time are typically a range of estimates and not a single value; think of estimates existing as a cumulative distribution function. A 50% confidence estimate is essentially an aggressive estimate where the estimator only has a 50% confidence that the task will be completed within the associated time value. A 90% confidence estimate is essentially a conservative estimate where the estimator has a 90% confidence that the task will be completed within the associated time value. [Agile Estimating and Planning. Mike Cohn.]

Parking lot chart

A parking lot chart is an agile artifact used to organize and categorize user stories by theme. A parking lot chart typically includes the name of the identified themes, the number of stories and story points it includes, and a progress chart to show the completion percentage of story points. For example, a parking lot chart could have a theme of ‘database’ with 6 user stories worth 80 story points at a 50% completion. A 50% completion would indicate that 40 story points had been completed, but NOT necessarily that 3 stories had been completed because not all stories are equivalent in effort. [Agile Estimating and Planning. Mike Cohn.]

Planning poker

Planning poker is a common agile estimation technique used to estimate the relative point value of a user story. [Agile Estimating and Planning. Mike Cohn.]

Planning poker is based upon the wideband Delphi estimation technique. It is a consensus-based technique for estimating effort. Sometimes called scrum poker, it is a technique for a relative estimation of effort, typically in story points, to develop a user story. At a planning poker meeting, each estimator is given an identical deck of planning poker cards with a wide range of values.

The Fibonacci sequence is often used for values for planning poker (i.e., 0, 1, 1, 2, 3, 5,8,etc.); another common sequence is (question mark, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, and 100).

A planning poker meeting works as follows :

1) a moderator, not estimating, facilitates the meeting.

2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote.

3) Each estimator selects an estimate of work effort by selecting a card,

4) Once everyone has selected a card, everyone overturns their card concurrently,

5) Estimators with high and low estimates are given a chance to defend positions.

6) The process repeats until there is consensus. The developer who owns the user story is typically given higher credence. [Agile Estimating and Planning. Mike Cohn.]

Product backlog

The product backlog initially serves as a rough estimate of the product’s requirements [Agile Estimating and Planning. Mike Cohn.]

One of the attributes of a Product Backlog is that it is EMERGENT (from the acronym DEEP). It keeps evolving as time progresses. It never gets frozen.

Reference point user story

The reference point user story for planning poker is typically a medium or average size user story. Estimators can use the reference point to make relative estimations. [Agile Estimating and Planning. Mike Cohn.]

Story points

A fixed and relative value of development effort.

Story points represent the relative work effort it takes to develop a user story. Each point represents a fixed value of development effort. When estimating the agile team must consider complexity, effort, risk, and inter-dependencies. [Agile Estimating and Planning. Mike Cohn.]

A story point is a fixed unit of development effort. It is used in the relative sizing of user stories to estimate work effort involved with development. Story points are not time-based, meaning [Agile Estimating and Planning. Mike Cohn.]

Agile teams typically use story points to estimate the relative size or effort of developing a user story [Agile Estimating and Planning. Mike Cohn.]

User story

– User story time-boxed value

Two to three minutes is a typical time-boxed value for discussing user stories when playing planning poker. [Agile Estimating and Planning. Mike Cohn.]

– Triangulation

Triangulation involves estimating the relative effort of developing a user story by comparing it against two other user stories. [Agile Estimating and Planning. Mike Cohn.]

– Vague and unclear user story

When an agile team is scoring a particularly vague and unclear user story, it typically assigns it a high value knowing that it will most likely become further defined in upcoming iterations. [Agile Estimating and Planning. Mike Cohn.]

Assign the user story an arbitrarily high number.

Tasks

It is appropriate to estimate tasks both during iteration planning and throughout the iteration. [Agile Estimating and Planning. Mike Cohn.]

Revenue

– Additional revenue

Additional revenue is revenue realized through the sales of new product features or services to existing customers. [Agile Estimating and Planning. Mike Cohn.]

– Retained revenue

Retained revenue is revenue retained through the development of new product features or services that prevent existing customers from stopping use of the existing product. [Agile Estimating and Planning. Mike Cohn.]

– New revenue

New revenue is revenue realized through the sales of products or services to new customers. [Agile Estimating and Planning. Mike Cohn.]

Velocity

Velocity is a measure of the number of user story points or stories completed by a team per iteration. An agile team can use its previous velocity recordings as a method of estimating how many user story points it may complete in the next iteration. [Agile Estimating and Planning. Mike Cohn.]

Estimating how many user story points a team can complete in a sprint/iteration should be based upon its previous iterations, if possible. If Kyle’s team estimated 45 story points in its first sprint but completed only 30 story points, it would be wise to estimate no more than 30 for its next sprint/iteration. [Agile Estimating and Planning. Mike Cohn.]

Wide band Delphi

A group estimation technique.

The Wideband Delphi estimation method is a consensus-based technique for estimating effort. It derives from the Delphi method which was developed in the 1950-1960s at the RAND Corporation as a forecasting tool. It has since been adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts.

Barry Boehm and John A. Farquhar originated the Wideband variant of the Delphi method in the 1970s. They called it « wideband » because, compared to the existing delphi method, the new method involved greater interaction and more communication between those participating. The method was popularized by Boehm’s book Software Engineering Economics (1981).

Original steps :

– Coordinator presents each expert with a specification and an estimation form.

– Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.

– Experts fill out forms anonymously.

– Coordinator prepares and distributes a summary of the estimates

– Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely

– Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.

Where is it effective ?

For making top-down estimates in situations where there are a lot of unknowns or various kinds of domain knowledge required. Especially useful for early estimates of large, not-yet-well-understood projects — estimates upon which we base our go/no-go decisions and early expectation-setting for upper management and customers.

How does it work?

– step 1 : Schedule the estimation meeting for a particular project or set of projects. The estimators should be team members (and possibly other stakeholders) who are very knowledgeable about the project, and from whom you need buy-in for the schedule of the project. 3-5 estimators is the sweet spot, although much larger groups can work, by breaking them into 3-5 person sub-groups and then combining those estimates.

– step 2 : Describe what the group is estimating. What part of the project, goals, or outcome are we estimating? What types of resources are we going to include? What units (ideal man-days or man-months, story points, etc.) will we use?

– step 3 : Ask everyone to estimate individually and privately using their best, instinctual judgement on the estimate. Give them enough time (5-20 minutes) to do this work quietly. Once people are familiar, you may be able to ask them to do this before the estimation meeting. Ask them also to take note of the assumptions and major pieces of work that led to the estimate — they’ll use these later in the group discussion. The private/anonymous aspect of this first round of estimates is important: we’re specifically empowering each person to express their gut instinct, and not be influenced by group think yet.

– step 4 : Show the results on a spreadsheet or whiteboard, and discuss. The group can see how divergent or convergent their estimates are. Ask each person (but especially the high/low or other interesting estimators) to explain how they got to their estimate — major assumptions, things included, etc. People will be reminded of things they forgot to include in their estimates. They’ll also be forced to confront different assumptions (which you may be able to quickly decide upon). All of which will improve future rounds of estimates.

Repeat steps 3 & 4 for a total of 2-3 rounds. After round one, anonymity is dropped and discussions can be short (the moderator should make decisions on behalf of group, for expediency and just for the purposes of the estimate). Often only 2 rounds total are needed to see estimates converge somewhat. A common effect is estimates converge together and up as people realize from the discussions the things they missed from their initial estimates.

Planning poker

Planning poker is based upon the wideband Delphi estimation technique. It is a consensus-based technique for estimating effort. Sometimes called scrum poker, it is a technique for a relative estimation of effort, typically in story points, to develop a user story. At a planning poker meeting, each estimator is given an identical deck of planning poker cards with a wide range of values. The Fibonacci sequence is often used for values for planning poker (i.e., 0, 1, 1, 2, 3, 5, 8, 13, etc.).

A planning poker meeting works as follows:

1) a moderator, not estimating, facilitates the meeting.

2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote.

3) Each estimator selects an estimate of work effort by selecting a card,

4) Once everyone has selected a card, everyone overturns their card concurrently,

5) Estimators with high and low estimates are given a chance to defend positions.

6) The process repeats until there is consensus. The developer who owns the user story is typically given higher credence. [Agile Estimating and Planning. Mike Cohn.]

Advices :

1) a moderator, not estimating, facilitates the meeting

2) the product owner/manager provides a short overview of the user story and answers clarifying questions posed by the developers. Typically the product owner does not vote

3) Each estimator selects an estimate of work effort by selecting a card

4) Once everyone has selected a card, everyone overturns their card concurrently

5) Estimators with high and low estimates are given a chance to defend positions

6) The process repeats until there is consensus

7) The developer who owns the user story is typically given higher credence

Planning poker = scrum poker

The presence of a product owner is necessary when playing a game of planning poker because the product owner provides an overview of user stories and answers any questions the development team may have.