Understanding the feedback in ‘The Feedback Loop’

What is Feedback?

Feedback occurs when the return of information concerning the results of a process or activity takes place (http://www.thefreedictionary.com.). This event is part of a chain of cause-and-effect that forms a loop onto itself. Feedback comes in two forms: good feedback and bad feedback. Without feedback, the Agile process of inspection and adaption could not occur. An Agile process thrives in an environment with constant change. Because of this variability, adaptation and adjustment points are made on a regular basis. If we can shorten the amount of time elapsed between these calibration points, then we can more quickly adapt to these changing realities. In short, this is the feedback loop in our process and environment.

Types of Feedback

There are, however, different forms of feedback, which are listed here for the reader’s reference and throughout:

  1. Communication feedback (e.g., onsite customer, open team workspace, ubiquitous language)
  2. Technology feedback (tools we use to give us quick feedback, like Cruise Control, mocking, BigVisibleCruise, CCtray, Resharper, TFS real time compilation/warnings, and confirming that we use the right technology)
  3. Requirement feedback (when a customer need realizes in a demo or the production environment)
  4. Market feedback (to see how the market reacts to a new story/feature/module, frequent and numerous deployments)
  5. Analysis, design and coding feedback (e.g., pair programming, whiteboard mockups, code reviews)
  6. Defect and testing feedback (the quicker we find out about bugs, the quicker we can fix them, deploying often and always, test driven development)
  7. Operational feedback (process, methodologies, practices and how to improve them)

The quicker we can get these forms of feedback from the source, the faster we can validate our progress and adapt to the information received.

A company’s ability to deal with change and adapt accordingly to changing conditions will improve its competitiveness in the marketplace. Companies that struggle with a slow feedback loop will find themselves caught up in trying to solve problems that have already changed or are not important anymore.

Effects of a fast feedback loop

Having a fast feedback loop allows dominance of a company during market changes. For example, one of our clients using our health and safety management system had a deadline for submission of reports. Approximately 800 companies assigned to each performed various tasks and submitted reports showing the work completed. There were some features and latency problems that the client wanted to be fixed, and the deadline was one week away. We were able to get quickly the high-priority features added, and latency issues resolved three days into the week using our engineering practices, automated testing, and automated deployments. We went live before the deadline to get much-needed feedback on our changes in a real production environment. If we had waited until after the deadline, we wouldn’t have obtained the actual feedback from the end users re the added features, nor the feedback from an environment production perspective, since the client wouldn’t be using the system until the next deadline, which was months away. Using this feedback from deployed features in a production environment allowed us to make more improvements so that the next period time would go even more smoothly.


Being able to perform a full cycle of development from client request to production deployment in a few days helps ensure the company can quickly adapt to changing market conditions.

(This is an excerpt from the mini book series “Agile from the Trenches: The Feedback Loop”)

How Measuring Velocity Helps in Your Agile Journey

Measuring velocity is a useful way of determining how long an agile project will take to complete, by providing a rough estimate of the amount of work the team can complete in a sprint.  It is necessary to keep in mind, however, that as insightful as knowing your team’s velocity is, velocity is not a true measure of your product’s development.

This post will discuss what velocity is and the reason why we measure it, and why management is interested in higher versus lower velocity.

Velocity Defined

Velocity, in terms of agile product management, is a metric that provides insight into approximately how much work a given team can complete in a sprint.  Measuring velocity uses information from a completed sprint, so if your team is approaching its first sprint, you must know how many people will be involved in the project, the maximum amount of work each person can complete, and the total number of workdays in the sprint, in order to calculate the velocity.

Calculating velocity involves units of work that can be defined as hours or story points – a metric capturing the complexity of implementing a story – for example, and tasks.  Velocity is calculated by adding up the difficulty metric of every backlog task, such as stories, completed by the team in a given sprint with the units of work for those tasks.  This provides the velocity in terms of units of work per sprint.

Why Measure Velocity?

Velocity provides an estimate of how much work your team, specifically, can complete in a given sprint.  As velocity is calculated using the work of previous sprints and if everything remains constant – such as the same people are involved and the tasks are relatively of the same nature – then velocity is consistent.  If the team had a velocity of 30 story points per sprint for previous software development projects, then it can be expected that, all else constant, the team will have a velocity of 30 story points per sprint in the next software development project.

Velocity is useful in estimating the approximate length that a project will take, as well.  If the project at hand has 120 story points’ worth of stories, and previous sprints show that the team has a velocity of 30 story points per sprint, then it can be expected that the team will complete the present project in four sprints.

Higher Velocity Versus Lower Velocity

As velocity signifies an agile team’s productivity – the velocity value indicates that either the team completed fewer high-difficulty stories, or they completed many stories of lower difficulty – it is more desirable for a team to have a higher velocity than a lower one.  A higher velocity would indicate that the team is capable of completing more stories or high-difficulty stories, which translate into more progress towards the project.

It is worth noting, though, that when teams are measuring their velocity at the start of a project, the velocity value will not be as accurate as it will be for later sprints.  An underestimation when initially measuring velocity can result in a higher velocity later on in the project.  Similarly, an overestimation in initially measuring the velocity will lead to a lower velocity later on in the project, as the velocity is adjusted with each completed sprint.  As such, the velocity value that is calculated later on in a project may not accurately reflect the team’s productivity; their productivity could have remained constant, yet the change in velocity value may be due to an under or overestimation.

Velocity Is Not a True Measure of Product Development

As useful as measuring velocity is, an agile team should not rely on their velocity to indicate the progress of their product’s development.  The velocity is measured based on each sprint, and with each new sprint, new product features’ information is accumulated and added; this changes the stories and story points associated with the next sprint, so the previous sprint’s velocity is not necessarily indicative of the team’s work in the next sprint.  Many new features may have to be added or changed in the next sprint, so the nearly completed product of the previous sprint may actually be 40% completed, given the previous sprint’s feedback.  Even though the team had a high velocity in the previous sprint, product feedback necessitated even more work before the product can be deemed complete.

{Photo courtesy: Flickr/Jan-Hendrik Palic}

How Can You Get More Effective with DevOps?

Here’s the excerpt of my recent article published in Better Software Magazine, :

The promise of DevOps is to provide a basis of collaboration between organizations and IT that produces superior customer value.

One of the most recent changes in the operations and delivery surrounding IT has been a new awareness of how critical sup- port for ongoing operations is, and how the value chain should continue to improve for the various businesses that IT sup- ports. For large and fair-sized corporations, where the core business is anything but IT, popular opinion suggests that IT is perceived to consume company profits—essentially, a cost center. This has led to a high level of scrutiny in recent years, especially with tighter budgets and shrinking profits. The need for tight control of expenditures in IT development and support to keep the network running smoothly is a growing concern for the CIO and CFO. In effect, this has turned into a struggle between the need to main- tain tight operations with minimum expenditures and resources while attempting to maximize support and continuing to produce results. …

Download the Better Software Magazine’s July/August 2014 Edition here to read the full article.

How to Be a Stellar Product Owner

Here’s the repost of my recent post on ScrumAlliance.org:

As we get into the routine of releases and sprints, over time the Scrum team establishes its work pattern, and the product owner (PO) becomes more familiar with not only the team but with methods for developing the product build with agility. As we move into sprint after sprint, daily stand-ups, planning, review, and retrospective sessions become second nature for the team. During this process, the PO may feel overwhelmed by the demands of involvement with the team, as well as the demands of external priorities. Some POs may lose their focus on the team as those external priorities shift. To address this and a few other factors that can affect the transition from being an average PO to being a stellar PO, I’ve listed some traits that can help a PO move in that direction.

A stellar PO makes himself or herself available to the team.

Product ownership is more than just a minor commitment — active participation in team gatherings is essential. A stellar PO must also commit to assisting with the resolution of various impediments affecting the team and with keeping product development on track, which requires more than a fair share of commitment.

Product ownership may be not a full-time job, but it needs sincere, dedicated attention from the PO so that the team gets queries answered and clarified, so they can keep development continuous, without any hiccups.

While the PO makes sure that his or her availability is active and ongoing for the team, the team should make sure that they respect the PO’s time, making productive use of everyone’s time during various Scrum ceremonies and activities.

A stellar PO is knowledgeable about the product being developed.

One of the key factors that every PO should know is the organization’s end-user market. Without that knowledge, any PO could unintentionally derail the team and lead them in the wrong direction — and on toward failure. The PO must be well versed in each and every end-user requirement.

From the team’s perspective, the PO is a powerful and resourceful representative for the business (as it pertains to a specific product within a business unit). As such, a stellar PO should have access to all pertinent information and should have full authority to guide product decisions in the right manner through the various Scrum ceremonies.

The PO represents the business and speaks on behalf of the business — any conflicts or issues encountered during development must be resolved by a single voice in the favor of customer value and end-user benefit.

A stellar PO is empowered.

With two-week sprint cycles, the entire duration is crucial for completing, testing, and potentially shipping the number of stories selected by the team. Since time is of the essence here, it becomes absolutely essential for the PO to respond in a timely manner to all requests for information or clarification that are sent his way by the team. Promptness, being on top of things, and fighting fires for the team is the key to the success of the project.

POs are direct business representatives (at least that’s the expectation), and it is expected that part of the PO’s role is to provide ready access to decision makers or influencers. In the absence of such access, crucial development decisions can be delayed and progress slows down — or comes to a halt — as the team struggles with issues that the PO should be able to easily manage. The result is incomplete stories and an unsatisfactory sprint outcome for the end user.

One of the strong traits that a stellar PO exhibits is acting as an advocate for the team. Teams that receive essential and accurate product direction and support build a higher-value business product. The stellar PO should take every opportunity to demonstrate advocacy for the team.


If you think of the product development cycle as a train, the team is part of the engine and the PO acts as its conductor. As developers move the process forward (acting much like an engine), they improve efficiency with every effort applied to delivery, and they help move the product as directed by their conductor, the PO, according to the defined and accepted stories and requirements. The conductor keeps the product train on track so it reaches every determined station (sprint completion) with the allotted resources and within the set time frames. Both the conductor and the engine must work together to get the product train to the right station with the right requirements and resources, in one piece and on time — each representing half of the equation toward reaching the solution. The PO and the team are core partners on this “journey,” and their profit is ultimately measured by building a high-value business product for their customers.

Lean Building: Understanding Waste and Managing It with Agile

Here’s the excerpt of my recent post on ScrumAlliance.org:

Within the context of product development and manufacturing, Lean management is essentially an efficient means of controlling production costs and maximizing profit over the product life cycle while avoiding and reducing defects and scrap (wasted effort, time, and resources). Waste typically occurs in the form of excess inventory, production, resources, or processes. This is valid for the manufacturing industry but is applicable to other industries as well, though the terminology may change.

There are eight areas of waste defined in Lean management:

  1. Transport: Moving people, products, and information
  2. Overproduction: Producing more than is immediately required
  3. Waiting: For parts, information, instructions, resources, and equipment
  4. Inventory: Warehousing parts, pieces, and documentation ahead of requirements
  5. Skills: Underusing staff capabilities or delegating tasks beyond scope and training…

To read more, please go to ScrumAlliance.org >>