Quit delivering Projects, Start delivering Value!

In a nutshell, Agile is an iterative approach to project management, not only restricted to software development, that helps faster delivery of value, in small increments, instead of delivering the whole scope at once.

The whole idea behind Agile practices can be summarized with the following two concepts:

I) Delivery quickly and deliver constantly.

Deliver the bare minimum and improve over time. If the idea is to deliver mobility by means of fashioning a car, do not allow the client to only go mobile after the completion of the car, the value in this scenario would be to allow the client to go faster and safer after each iteration, therefore, value is delivered incrementally from the start of the project instead of all at once upon its completion.

II) Keep it simple.

Do not waste resources. The defined goal’s essence is what really creates value, all other features and technical bits and pieces are “nice-to-haves” or gold-plating, focus on the essence of what must be achieved in order to reach the committed goals, anything that does not somehow contribute to producing customer value should be questioned.

Also, by means of delivering the bare minimum product that meets the client’s expectations, which is the definition of Agile’s MVP (Minimum Viable Product), balancing between usability and efficiency, helps entrepreneurs deliver an idea of the product earlier in process, avoiding uninformed decisions, and most importantly, receiving the client’s feedback before releasing a fully-developed product. If necessary, more value can be added to the deliverable by means of new iterations.

1)     When and Why to choose Agile?

In a plan-driven defined business process model, such as Waterfall project management, it is required to understand and define, in advance, every piece of work to be performed. To exemplify, we can think about a recipe to prepare a dish, which is a well-defined set of instructions that completely dictates, step-by-step, everything which is necessary in order to produce the dish, therefore, it is feasible to plan all the efforts regarding time, materials and cost, consequently, the process is predictable and limited in changes.

Consequently, in this methodology, upon identifying a problem to be addressed or solution to be implemented,  several discrete phases would be defined, such as “Gather Requirements”, ”Design the Solution” and “Deploy” (said phases are often visually portrayed in cascading diagrams and follow a progressive sequence of phases, as a waterfall, hence its name), then upon completion of every defined phase, the product would finally surface in its entirety. Waterfall is a sequential, linear process of project management, thus no phase begins until the prior phase is completed, as well as it does not allow the return to a previous phase, the only way to revisit a phase is to start over at phase one, therefore, this approach can be unforgiving, as success or failure, is realized in largest part at the end of the project.

Unfortunately, not all processes are well-defined regarding business and goals, the Agile mindset is designed for situations where the result to be achieved is uncertain and/or the process to produce the desired outcome is not well known or defined, thus, due to the level of uncertainty,  a trial and error approach, common to adaptative models which rely heavily on inspections to adapt the results as they are assembled, would be better suited, in order to verify if the deliverable meets the expectations.

Disregarding the methodology, all projects start with a level of uncertainty, the planning phase attempts to remove the uncertainty by more clearly, and to a low level, define the objectives, processes, and tasks necessary in order to produce the desired deliverable prior to the development or implementation, which may be reasonable with certain types of projects. However, this approach cannot be utilized when the project has high levels of uncertainty, for it may force the employment of large amounts of assumptions based on incomplete, inaccurate, or faulty information.

Agile rather than attempting to remove all uncertainty upfront, defines the desired outcome at a high level, then breaks the project into iterations, in this scenario, only the planning regarding the current iteration must be done, instead of the whole project at once. Each iteration delivers continuous subsets of high-value features, often delivering feasible increments of functionality for users.

The key takeaways are that a typical plan-driven project attempts to reduce the level of uncertainty associated with projects at a very low level prior to the start of the development, whereas Agile progressively reduces the uncertainty at each iteration, rather than artificially forcing low levels of uncertainty, as well as while plan-driven projects only deliver a complete solution at the very end, Agile approach delivers value in small increments, demonstrating value earlier and continuously, increasing project visibility and forecasting, as well as reducing risks as deviations are recognized quicker.

It is crucial to highlight that Agile does not replace prior management models, for it is not suited for every scenario. Both plan-driven and Agile models aim to deliver the same value, the difference is “How”, both approaches have their advantages and disadvantages, depending on the specific project to be performed, it is more beneficial to openly acknowledge the environment and uncertainties and use a project model accordingly.

In consequence, if the workplace has excessive bureaucracy, approvals take a long time, or if the project is business-centric, scope-fixed, and demands a longer-term delivery with a focus on requirements, Agile may not be the best solution. Instead, if the value must be delivered quickly, delivered often, collaboratively and the scope can be variable and negotiable based on continuous reflection, the project is suited for Agile.

Plan-driven methodologies primary emphasis’ is on managing scope to control costs and schedule, normally achieved by controlling changes in the requirements. The project is successful if it is delivered within a given schedule and budget, in order words, respecting the “Iron-triangle” (Requirements, Resources, and Time), which may lead to inflexible management, not adaptive to uncertainty.

The Agile mindset intends to flip these factors, for it presumes resources to be fixed by the development team's capacity of delivery, and time to be constrained by time-boxes (where each time-box can be faced as a small project), leaving requirements to be flexible, for, in Agile, change is a norm rather than an exception, the emphasis is always to maximize the business value to the client rather than controlling the scope.

Agile does not disregard the importance of scope, for it defines and outlines the goals to be achieved as well as the overall value the be delivered, however, the project sponsors should determine the appropriate level of emphasis between control of scope and flexibility.

By breaking the projects down into smaller and more manageable bits of user functionality, enables the ability to monitor the incremental value produced by the project against its incremental cost as it progresses, which can be a huge factor in reducing the risk of a project, for the development teams can more quickly adapt to incomplete or changing requirements, reducing wastes and re-work while also providing earlier assurance that the product meets user expectations.

As a result, when the type of project to be conducted and the environment enables the adoption of Agile practices, the major benefits of doing so are regarding visibility, risk, and value perspectives.

I) Visibility:

Supported by frequent deliveries, and user feedback, Agile provides continuous visibility of the project’s progress and outcomes, as opposed by the value being delivered at the end of the plan-driven centered project, where the product has limited visibility until the very end.

II) Risk:

Due to Agile’s continuous testing and delivery, there is higher transparency regarding delays, defects, or missed value. Early recognition of these risks permits earlier intervention, whereas Waterfall’s deliverable is held until project completion, therefore, delays or lack of value and missed opportunities, generally are not recognized until it is too late to intervene.

III) Value:

Agile projects deliver and demonstrate increments of value throughout the project, and the highest value features are delivered first, while Waterfall projects deliver all value at the end of the project.

It is tempting to become a champion of one methodology, especially if you’re used to it, but it is important to remember that a successful methodology not only assists in delivering the project without surpassing the budget and schedule, but assists as well in producing valuable, workable product.

Agile and plan-driven philosophies are often misunderstood as separated domains of management, with no integration between the two, however, both principles are not a binary, mutually exclusive choice. Accordingly to the type of project, uncertainties, challenges presented and customer’s expectations, it may be erroneous to attempt to force-fit the project into one of the two “extremes”, the right approach would be to go in the other direction, and fit the approach correspondingly to the project’s nature, blending plan-driven and Agile techniques in the right proportion regarding the presented situation.

In practice, it makes sense and it is feasible to create a hybrid approach of plan-driven and adaptative mindsets, as for instance, Waterfall can be utilized in the initial phase of the project, regarding the gathering of requirements and documentation, then switch to Agile for execution and implementation, essentially utilizing the best of both worlds, for the hybrid method retains the clarity and tracking system of the plan-driven method, while embracing the adaptability, flexibility, continuous feedback and delivery of Agile.

It will be up to you and your organization to determine the most suited approach for each scenario, which must take into account the nature of the problem to be solved and organizational environment, for instance, if the organization is transitioning to the Agile philosophy, but the complexity involved is setting progress back, for the Agile philosophy has many "moving" parts and takes time for teams to adopt it successfully, it may be worth using the well-known Waterfall method and slowly incorporating Agile techniques until everyone can transition to a fully Agile methodology.

Another example is when the project has a defined budget and delivery date, but would benefit from Agile’s fast design, development, and feedback cycles. Waterfall methodology could be used at the enterprise level (planning, design, and requirements definition), and the Agile approach at a project level (development and test in short time-boxes).

Furthermore, the organization may choose to cherry-pick Agile components and apply them to a Waterfall methodology, such as the use of the Kanban boards to keep communication flowing and progress tracking, as well as the adoption of certain Scrum’s ceremonies to enable higher visibility of what is being developed, gathering the client’s feedback.

2) What is Agile?

Agile mindset has its roots in software development, it aimed to provide a new approach to excessive planning and documentation in order to enable development cycles and speeding up the time to market for new products and features, for companies were so focused on scope control, that they lost sight of what really matters, which is delivering value to the client.

One of the major influences for Agile conception is the philosophy behind the Total Quality Management methodology (TQM), by which both managers and employees can become involved in continuous improvement in the production of goods and services, emphasizing getting the work done right the first time, and eliminating re-works.

Lean Manufacturing concepts such as “Cease dependence on inspection and build quality into the product”, which means that everyone needs to be responsible for the quality, are also basis for the Agile mindset. It is not up to the Quality department to find defects in the deliverable, in this mindset, roles are allowed to blur, therefore, developers can hold acceptance tests continuously throughout the process, which not only reduces defects but also produces a product that is going to provide higher levels of user satisfaction, for the users are much more engaged in providing input and feedback as the project progresses.

In this scenario the Agile Manifesto was conceived, which dictates the principles and values of this mindset, although software-centered, it is not solely for developers and project managers, being able to be applied to diverse fields, industries, sectors, and projects.

The four major values for Agile project management are:

I) Individuals and iterations over process and tools.

Agile does not disregard the use of project management tools, for instance, Agile projects uses well defined and established processes such as Scrum, however, the process itself is much more adaptative, aiming to facilitate human interactions, which is particularly crucial in an uncertain environment or in a scenario that requires creativity and innovation.

II) Working software over comprehensive documentation.

Unlike Waterfall projects which require documentation of what was achieved as a deliverable at the end of each phase, Agile is not documentation intensive, for instance, tools that are designed to facilitate collaboration and communication, such as Scrum or Kanban boards, can take the place of hardcopy documentation.

Typically in Waterfall projects, the end-user does not glimpse the deliverable until the final user acceptance testing, at the very end of the project, and due to the difficulties and/or its level of uncertainty presented when defining detailed requirements upfront for the project, relying heavily on documentation can lead to significant miscommunications regarding the intent of the requirement, which at this stage can be both expensive or not technically feasible to perform changes in the deliverable, due to time and/or costs restrictions.

III) Customer collaboration over contract negotiation.

If the project is Agile-based, it usually means that the requirements are somewhat uncertain, therefore, requirements and goals can be re-defined along the project's course. A partnership between client and Development Team is necessary in order to manage tradeoffs, as in contrast to Waterfall projects, where typically a contract strongly defines requirements within a given schedule.

The flexibility in the contract should be consistent with the nature of the requirements, both sides need a mutual understanding of the level of uncertainty in the requirements and how the contract will be managed, therefore it is better to create a general agreement based on some high-level requirements and work out the details as the project progresses.

IV) Responding to change over following a plan.

It does not mean that Agile projects are unplanned, it is like visiting another country in your vacation, you do not plan everything you want to do by the minute, instead, you probably have some general goals for the thing you want to do, but have flexibility do develop more detailed plans once you are abroad, that is, when more and better information will be available.

We are immersed in a highly dynamic market, the whole scenario that was defined by scope can change six months in advance, when the project may be due to be delivered. Without the adaptability inherent of Agile's mindset, it is possible to deliver everything defined by scope, however, due to the change in the scenario, the solution may not have value to the client anymore.

Additionally to its four values, the Agile Manifesto also outlines twelve principles for agile development practices. These twelve principles emphasize early and continuous delivery of value and continuous attention to technical excellence as can be verified below:

I) Our highest priority is to satisfy the customer through early and continuous delivery of value.

Not only working deliverable is a good measure of progress, but it also provides the opportunity for the client to inspect the deliverable early in the development/implementation cycle, the client’s input is key to deliver value and mistakes can be rapidly addressed.

To this endeavor, breaking up the effort into well-defined pieces, that each has well-defined criteria for being considered “Done”, provides a much more tangible and objective way of measuring progress.

II) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Change is expected and welcomed rather than rigidly controlled and limited, however, it is important that the project team and the client have a mutual understanding upfront of how the changes will be managed.

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

Agile development processes are based on continuous improvement, breaking the requirements into short time-boxes of development/implementation, upon which the deliverable can be inspected by the stakeholders, and if it is going in the wrong direction, its course can be quickly fixed. A common saying in Agile is “Fail early, fail often”, for it gives the sponsor, project manager, and team, the opportunity to recover and see hidden or small failures and resolve them quickly. In many cases, it is better to try something quickly, learn from it, and make the necessary adjustments faster.

IV) Businesspeople and developers must work together daily throughout the project.

Designing an approach that gets the right people engaged at the right time is very important for making the project successful, therefore, a higher level of engagement from the business sponsors and stakeholders, which are the holders of the solution’s view, is necessary, as opposed to the responsibility of the development/implementation to be delegated only to the development team. The degree of engagement should be according to the nature of the project.

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

Too often in the past, defined business process models used high-pressure, command-and-control tactics to coerce the project team into delivering results faster. In an environment that requires high levels of creativity and innovation this approach does not works, the philosophy of Agile is based on high-level of empowerment and individual initiative by the professional on the project, for developers are given a general direction and are free to figure out how to get it done more effectively by themselves, but it does not mean that there is no leadership whatsoever, the leadership style must fit the situation, managers (known as “Scrum Masters” in Agile) can make sure that team members have, or obtain, the right skill sets, or steps up when the assembled team still does not have the maturity to be self-organized, or try and are unable to resolve issues.

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

As opposed to Waterfall’s methodology, which heavily relies on documentation as a way of communications, Agile encourages developers and stakeholder’s communication, as a means of more clearly express themselves, although, it does not exclude the need for formal communication, the right mix will depend on a number of factors including the scope and complexity of the project.

VII) Working software is the primary measure of progress.

In a software project, you typically do not know how complete the product really is until it has been tested and validated to be complete, therefore, any estimated percentage of completion is likely to be suspect. A more accurate measurement of progress would be to break up the software, or any deliverable, into chunks of functionality, where each chunk can be demonstrated to the user for feedback and acceptance.

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

Many of the underpinnings of Agile come from Lean Manufacturing and Total Quality Management, therefore, in a situation that relies heavily on creativity, it is paramount to create a sustainable work environment over a long period of time.

IX) Continuous attention to technical excellence and good design enhances agility.

Agile recognizes the need for doing things the right way to avoid unnecessary re-work later, however, should not result in over-designing or gold-plating a product either. The work should be done to a sufficient level of completeness and quality to fulfill the purpose it was intended to fill and nothing more.

X) Simplicity–the art of maximizing the amount of work not done–is essential.

It is not unusual for projects to go out of control, for the requirements become way too complex, therefore, difficult to implement. An important Agile concept is the MVP (Minimum Viable Product), which defines the minimum set of functional features a product must have to meet the passing criteria, it is generally much more effective to take an incremental approach, to start with something simple, and then expand it only as necessary.

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

The idea is that high-performance cross-functional teams, which have all competencies needed to accomplish the work without depending on external assistance, that work collaboratively can produce superior results. Thus, if we have the right people on a team, and the team is empowered to collectively use all diverse skills among them in a collaborative manner, it will generally deliver a better result than a single individual could ever deliver acting alone, for self-organizing teams chooses how best to accomplish their work, rather than being directed by others outside the development team.

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

Agile is heavily based on continuous improvement and using short intervals to reflect on what is working and what is not working, taking quick corrections if and when necessary. Said action is called “Retrospective” in the Scrum framework and happens at the end of each development time-box. A focus on continuous improvement is essential to highly adaptive, empirical development processes.

As evidenced by the twelve principles, the key aspect that separates Agile from other approaches, is the focus on the people doing the work and how they work together making it possible to deliver more business values sooner, granting visibility of the progress being made, reducing the risk in the project and improving the team’s productivity (by means of less re-work) and discipline (empowering the development team).

Agile is an “umbrella term” for a set of frameworks and practices based on the values and principles expressed in the Agile Manifesto and the twelve principles behind it, such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).

Accordingly to studies released by stateofagile.com (14th Annual State of Agile Report. https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494), the most popular and widely used Agile framework is Scrum.

3) What is Scrum?

Scrum is a customer-centric, adaptative and flexible, Iterative time-boxed approach to incrementally deliver value based on continuous improvement, which means that both the process and the results are experimented on and adjusted based on observation throughout the process, and therefore, changes in the requirements are encouraged to maximize the value of the deliverable. Scrum describes a set of meetings, tools, and roles that supports teams’ structure and manage their work, encourages teams to learn through experiences, self-organizes while working on a problem, and reflects on their wins and losses to continuously improve.

To summarize, while Agile is “a way of working”, and Scrum is the most usual set of instructions for achieving the Agile mindset.

At a high level, a Scrum-centered project starts with a general vision of the deliverable that will be produced, which may or may not be elaborated at this stage, for it can be further detailed as the project progresses, and more information is obtained.

The vision will be expanded into a Product Backlog, which is a list of User Stories (short and succinct description of a specific item of functionality to be developed/implemented) which must be completed in order to fulfill said vision. The User Stories list is prioritized in order of business value, where the items that will have the highest ROI (Return of Investment) will be developed first, in order to deliver value as quickly as possible.

The Sprint, a fixed interval of time typically between two and four weeks in duration, is where the actual work gets done, instead of the plan-driven approach which expands the time required to fit the items to be developed, Scrum fixes the time for each iteration and selects small incremental items of functionality (User Stories) to be developed in the Sprint, fixing the work in a given amount of time. Said items are selected from the Product Backlog at the start of each sprint in an event called “Sprint Planning” and moved into the “Sprint Backlog”, in other words, moved to the list of items to be developed within the Sprint.

During the Sprint, the team meets daily to discuss and review progress, coordinate the team’s activities, discuss and remove obstacles to the progress. At its end, another meeting is held, the Sprint Review, to revisit the committed goals against the deliverables produced during the Sprint.

Although simple to understand, implementing the Scrum framework is not easy, it requires skill, training, and often changes in the organization’s mindset and culture. Scrum does not fix issues within the organization, it just makes all the obstacles and gaps more transparent, and if the team does not address said issues, poorly developed products will be delivered sooner, and doomed projects will fail faster.

Scrum’s key concepts are: 

· Roles: Scrum divides the team into three main roles which are Product Owner, Scrum Master and Development Team.

· Artifacts: Artifacts are something that is produced, which includes the Product Backlog and Sprint Backlog.

· Ceremonies: Set of sequential meetings that Scrum teams perform on a regular basis, which includes Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Teams use these events to execute tasks and refine/adjust the process.

I) Scrum roles:

I.I) Product Owner (PO):

The Product Owner is first and foremost the subject matter expert for the given project. The PO represents the business sponsors, keeps track of the project’s stakeholder’s expectations, is a decision-maker in the project, providing directions for the team on what will be developed, and prioritizing Backlog. The Product Owner has the ultimate authority over the final product, therefore, it is expected to be heavily engaged in the project as it progresses, additionally, the Product Owner defines the MVP (Minimum Viable Product) for each iteration.

The Product Owner is responsible for managing and deciding what User Stories are added into the Product Backlog and re-prioritizing each item prior to Sprint Planning meetings, as well as ensuring that the stories in the Product Backlog are presented in sufficient detail, so that they are thoroughly understood by the team, ensuring that the team know what needs to be done to complete each story and is able to plan Sprints effectively.

I.II) Scrum Master (SM):

The Scrum Master is a servant-leader with a high level of expertise in the scrum process, establishes responsibility for following the Scrum framework, providing guidance to the Scrum Team, facilitates meetings, and removes impediments or distractions that may prejudice the Development Team from completing tasks, as well as help those outside the Scrum Team to understand which of their interactions with the Scrum team are helpful and which are not, as well as ensuring that the Product Owner knows how to arrange the Product Backlog in order to maximize value.

Whereas in a traditional plan-driven project, the project manager is responsible for the overall success of the effort, thus this role is expected to drive people to achieve results, by managing the project timeline and resources within the well-defined scope in order to meet business requirements, fitting the coordination role in a more top-down hierarchical approach. Agile is based on a softer style of leadership, a Scrum Master helps empower the Scrum team to achieve its goals, ensures that the team is fully functional and productive, enables close cooperation across all roles, by coaching the Development Team in self-organization and cross-functionality, removing impediments to the Development Team’s progress and facilitating Scrum events as requested or needed, in a servant-leader manner.

Once not all teams have the level of maturity required to be self-empowered, the Scrum Master can assist in the Team’s coordination, hence he must be a strong, cross-functional leader as well.

I.III) Development Team:

Cross-functional team, composed normally of three to nine professionals, containing a diverse range of skills (as for example one member can be specialized in business mapping, other specialized in development and a third member expert in solution testing), which is a good formula for a high-performance team, however, the Team is expected to act as a single entity where all its members act cohesively, in a self-organizing manner, and each one is responsible for delivering the committed goal.

It is possible to think about the team as a running a restaurant, everyone has its own specific tasks, one is responsible for the meat aisle, other responsible for the pasta, but they all have to work together so all the components of the dishes come together at the right time, and they have to be able to make all sort of dishes based on what the customer happen to want each day. The team is only successful when the meal is satisfactorily delivered to the customer.

Even with specializations, Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person, as well as no sub-teams in the Development Team, regardless of domains that need to be addressed, such as testing, architecture, operations, or business analysis.

In an ideal Scrum scenario, the Development Team should be in the same room, sitting right next to each other, no matter which departments each one may be from, the sharing of the same space improves communication and enables work in a collaborative manner.

During the Sprint Planning ceremony, in collaboration with the Project Owner, the Team negotiates what the overall goals of the Sprint will be and what work will be done throughout the Sprint, forecasting how much work they believe they can perform over the iteration using their historical delivery as a guide, define and plan the tasks necessary in order to fill that commitment, consequently, the team needs to be self-empowered to do whatever is needed to deliver the committed activities to achieve the Sprint’s goal.

II) Artifacts:

II.I) Product Backlog

Is the master list of work that needs to get done, holding all work to be executed. It is a dynamic repertory of User Stories (features, requirements, enhancements, fixes and general tasks that will add value to the deliverable), which is continuously revisited and re-prioritized by the Product Owner, aiming to deliver the most business value as possible. All complete work is removed from the Product Backlog, and new features can be added.

User Stories contained within the Product Backlog must be independent, negotiable, valuable, estimable and testable in nature, as well as short, succinct, and self-explanatory regarding what is intended. A good formula to structure User Stories is “As a … I want … so that …”.

A Product Backlog is never complete, its earliest development lays out the initially best-understood requirements, however, the Product Backlog evolves as the deliverable and the environment in which it will be used evolves.

Each User Story has an estimated level of effort required for its completion, which is used to assist the Project Owner, when refining the Product Backlog, to understand the complexity of the item in the product backlog, versus the business value they provide, as well as assisting the tactical level in the Sprint Planning, to assess the total amount of work to be taken into the Sprint against the teams’ capacity, which based on the teams capacity history, therefore, it is common for the earliest capacity assessments to be inaccurate, for there is no frame to compare to.

Story Points are a metric commonly used in Agile projects for sizing the level of effort associated with a particular User Story. A story Point is normally not directly tied to any specific measure of time, it is a relative measurement of the level of difficulty for developing/implementing a particular User Story, relative to another User Story, therefore, a Story Point may not have the same meaning among different teams.

Story Points are usually expressed accordingly to a numerical range, such as an adaptation of the Fibonacci sequence (for instance 1, 2, 3, 5, 8, 13), due to its capability to provide the appropriate level of discrimination between small and large estimates, still, it is also common to use t-shirt size ranges, from XS to XXL.

Only the Development Team can estimate effort for Users Stories, a task most commonly fashioned in a “Planning Poker” session, which starts by providing a set of playing cards, numbered accordingly to the numerical range agreed for Story Points, to each Development Team member. Each User Story in the scope is then presented to the Team, any discussion regarding any significant uncertainties or questions are performed, then each member of the Team chooses a card representing their estimate in Story Points, however, they do not reveal their estimates to others just yet.

When everyone is ready to vote, all members of the Team display their selected cards simultaneously so one person’s vote does not influence another person’s estimates. The Team then discusses why their estimates diverged, trying to converge on a single estimate that everyone agrees to.

The time required to deliver the User Story may vary accordingly to the Team member responsible for its execution/development, yet, the level of effort (Story Points) remains the same.

Story Points also assists in pinpointing the Team’s velocity, for in Agile, velocity is expressed in terms of the number of the Story Points that a Team completes in one Sprint.

II.II) Sprint Backlog

List all User Stories selected from the Product Backlog, defined in conjunction by the development Team and Project Owner at the Sprint Planning ceremony, for implementation in the current iteration (Sprint cycle).

A Sprint Backlog can be flexible and evolve throughout the sprint. However, the fundamental Sprint goal, what the Team wants to achieve from the current sprint, cannot be compromised.

III) Scrum Ceremonies:

III.I) Sprint:

Typically, a fixed-length time-box, ranging from two to four weeks in duration, in which the team will work on a defined set of User Stories. Each User Story cannot be big enough that it cannot be accomplished in the defined sprint.

The more complex the work to be performed is, or the more uncertain the process or requirements are, the shorter the sprint should be, for feedbacks and re-negotiation between the Product Owner and the Development Team, if necessary.

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

Although rare, a Sprint can be canceled before its fixed-length time-box is over, in situations in which the Sprint’s goal no longer makes sense given the circumstances, for it may have become obsolete, or if market/technology conditions changes. However, only the Product Owner has the authority to cancel a Sprint, whilst he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. Any delivered Product Backlog items throughout the Sprint are reviewed, and incomplete Product Backlog Items are re-estimated and returned to the Product Backlog.

III.II) Sprint planning

Prior to this ceremony, which is typically time-boxed to four hours, the Product Backlog should be groomed (or refined - the act of adding details, estimates, and order items in the Product Backlog by value, as well as removing items that may no longer be relevant) and prioritized by the Product Owner, for only the items which will return most business value should be discussed.

The first phase of this ceremony is basically a negotiation between the Product Owner and the Development Team, regarding which stories will be taken into the Sprint Backlog, defining the Sprint goals. The Product Owner decides which stories are of highest priority and the team pushes back and voice concerns, based on the User Stories’ complexity, level of effort estimated to given User Story (only the Development Team can forecast the effort to given User Story), and Team’s average capacity (or velocity - number of Story Points the Team usually delivers over a sprint).

Upon defining which User Stories will be developed throughout the Sprint, the second phase of this ceremony takes place, normally without the Product Owner, in which the Team breaks down each committed User Stories into tasks that will be needed in order to fully produce the defined features, and how those stories will be allocated among the members of the team.

By the end of the Sprint Planning, the Development Team should be able to explain to both the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint goal and deliver the committed value.

Normally if a defined feature requires significant changes or enhancements throughout the Sprint, those will typically be added to the Product Backlog and deferred until a future Sprint Planning.

III.III) Daily Scrum:

Fundamentally a Team check-in, usually held in front of the project’s Scrum board every morning, around 15 minutes long in duration, where the Team monitor progress, making sure that everyone on the team is on the same page and aligned with the sprint goal, as well as providing an opportunity to voice concerns and identify impediments as well as to inspect how progress is trending toward completing the work in the Sprint Backlog.

Each person in the Team typically answers 3 questions regarding what was accomplished yesterday, what is the plan for today, and if obstacles are in the way, what is necessary to overcome them.

III.IV) Sprint Review:

Occurs always at the end of every Sprint, where what was planned is reviewed against what was delivered in the last sprint.

The deliverable produced throughout the Sprint is presented to the Project Owner, and other stakeholders, for final review and approval, basically a User Acceptance Test (UAT), yet, this should not be the first time the Project Owner checks the work against the acceptance criteria to determine if the work is satisfactory or not. A good practice is to demonstrate the features for feedback as soon as they are completed.

When a feature is delivered, tested, and validated, it does not mean that the development is finished, only that the particular User Story that was defined to be delivered at the end of the Sprint meet its “Definition of Done” (DoD), which is when all conditions, requirements or acceptance criteria, that a product must satisfy, are met. Each team has its own “Definition of Done" and acceptance criteria to determine when a User Story gets completed, ensuring quality and preventing User Stories that do not meet the Definition of Done from being promoted to higher-level environments (such as production or market).

All defects in the product should be resolved prior to the Sprint Review, unless the Project Owner has specifically approved deferring the resolution until a later sprint.

III.V)     Sprint retrospective:

Takes place after the Sprint Review, which purpose is for the Team and Product Owner to inspect itself and reflect on what went well, what did not go well, and identify opportunities for improvement regarding the Sprint conduction, the project as a whole, people, relationships, tools, or even for certain ceremonies. Although the Scrum framework provides tools as explained throughout this article, they are not mandatory rules, but guidelines, meaning that Teams have the ability to figure out how they are going to approach things on their own.

This is at most a three-hour meeting, in which attendees include the Scrum Team and key stakeholders invited by the Product Owner.

A graphical representation of Scrum’s framework workflow can be further explored below:

IV)               Scrum Board

A Scrum Board is the focal point of any Agile project, being a visual method that assists the Teams in making Sprint Backlog items visible and tracks the progress of work by splitting complex tasks into smaller chunks of manageable work within its swim lanes (which are usually “To-Do”, “In Progress”, “Blocked” and “Done”).

The board is always owned by one Scrum Team (and typically run by the Scrum Master), can take physical (whiteboard and stickers) or virtual (software tools) forms, being updated and referred by the Team during the Daily Scrum, keeping the team focused on the tasks that remain and their priorities.

The key ideas behind Scrum Boards are to boost transparency, centralizing the tracking of individual tasks within the Sprint cycle, allowing the Teams to quickly identify bottlenecks and impediments, as well as prioritize tasks (usually aided by color codes), and analyze their overall performance.

Scrum does not prescribe the format of a Scrum board, it is up for the Team to decide the most useful way of presenting the information it needs, enabling visualization and manipulation of the board all over the Team, however, it is typically divided into four vertical swim lanes labeled “To-Do”, “In Progress”, “Blocked” and “Done”.

Each member of the Team may have its activities for the current Sprint defined in the Sprint Planning meeting or pull one task to be completed, from the “To-Do” swim lane.

V) Scrum values:

Scrum is based upon a set of fundamental values which provide a code of behavior and ethics for teams to embody and live by as they work with Scrum. The Scrum Values imply distinct types of behavior, guiding the understanding and enacting the rules of Scrum.

It is expected that as the adoption of Scrum progresses, the fluidity of adoption of those values increases, as Scrum is understood better and enacted, taking precedence in people’s interactions and collaborative work, being a health indicator of your Scrum.

V.I)       Commitment:

Commitment in Scrum is about being dedicated to a cause, a goal, or a vision, the whole idea of self-organizing Teams is supported by the willingness to collectively dedicate ourselves to a goal and to do our best to meet that goal.

Without commitment, Scrum Teams will not be able to reach their full potential and will ultimately struggle to come up with valuable deliverables.

V.II)      Focus:

Once the deliverable items have been agreed to, they should not be radically changed mid-sprint, which means that Teams must concentrate on the committed activities rather than allowing them to be diverted or become distracted by support issues, on-demand work, emails, meetings, and so on.

Once the team is focused, they can dedicate all their efforts to resolving the problems and completing their goals in the simplest way possible, taking responsibility for and fulfilling the undertake commitments.

V.III)     Openness:

We strive to create an environment, among The Scrum Team and the project’s stakeholders, in which we feel safe to tell the truth regarding impediments, the performance of tests, delays in the schedule, re-works, and so on.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to allow progress to be visible to everyone. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt. Without real openness and honesty about its progress, learnings, and sharing feedbacks, a Scrum Team will struggle to gain trust and empowerment, not being able to reach its full capabilities.

V.IV)    Respect:

It is not unusual for the Development Team to be composed of personnel with different experiences, opinions, and cultures, there is a lot of value in hearing people with different points of view, and reaching consensus calls for respect.

An environment of respect generates trust, where different perspectives and views are encouraged, confidence and performance excel throughout cooperation and collaboration.

V.V)      Courage:

Scrum emphasizes the importance of self-organizing, cross-functional teams to optimize creativity and productivity. Be creative means that we must have the daring to come up with ways to deliver the best that we can and the endurance not to give up, is the audacity to take the risks required to produce innovative solutions, even in face of small spawn of time to produce results. Therefore, it is imperative that we have the determination and resolution to take ownership of the decisions we make (or fail to make) and the consequences of the result.

Not all deliverables will meet the expectations, not all activities will be completed on schedules, courage is also sharing bad news, even when they may be poorly received, avoiding burying information, or shifting blame when outcomes are negative.

To summarize, Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and dynamic environment, not all principles must be strictly followed, it is possible to mix plan-driven methodologies with Agile principles in order to and speed up deliveries and increase transparency, be Agile means to be adaptative to the environment presented, identify what uncertainty you’re facing, and figuring out how you can adapt to that as you go along.