Scrum takes its name from a play in rugby where the players bind together in teams and try to take back possession of the ball. Injuries are common.
‘Scrum’ as in Software Development
The description above is an apt metaphor for Scrum development. It is a lightweight team-based Agile framework that is focused on getting the ball down the field in the fastest, most efficient way possible. Scrum is used for developing complex products and services with a focus on developing incremental units of business value within short iterations. It requires honesty, communication & adaptability. Just like the Rugby scrum it can be painful, but incredibly effective.
Now, let’s breakdown the components of Scrum. It is comprised of roles, ceremonies, and artifacts.
The Product Owner (PO) is the individual who makes the decisions on anything related to the “product”. The PO’s key responsibility is to make sure the team is developing products and features that deliver business value. The PO represents the voice of the customer and other business stakeholders. They drive the vision of the product and its features; create and prioritize the product backlog; define acceptance criteria and ultimately accepts the output from the development team. The PO is essentially an implant from the business world into the scrum team, as they are considered the product champion with the complete product know-how.
The Scrum Master (SM) is the servant leader for the development team. The SM makes sure that the team is on track to deliver the product in increments and within the time-boxed sprint schedule (more on sprints in a bit). They facilitate through devotion to the scrum process, and by swiftly eliminating scrum team’s impediments. They uphold the structure of scrum, and inculcates the principles of agile within the scrum team. The SM is a facilitator for the scrum team, and makes sure that the development team is aware of what needs to be accomplished and when, and that they have the ability to self-organize to accomplish the development tasks.
Team Members / Development Team
The Team Members / Development Team (DT) are those responsible for the implementation of the product or features. These are the set of people who are actually doing the what that has been proposed and conceived through the product backlog and grooming sessions. The DT is usually a cross-disciplinary group of individuals including engineers, UI developers, Analysts and Quality Assurance. The DT self organizes and decides the best way to accomplish tasks they pick up during planning. They provide estimates on stories within the product backlog as well as provide feedback on the acceptance criteria to the PO to help keep development on the right track.
The Product Backlog is a prioritized list of epics and stories created and managed by the Product Owner (PO). An epic is a large story and there may be smaller stories contained within. The story describes the feature in a way that makes the business value and use for the customer clear to all stakeholders so everyone can understand what is being delivered. A story is an increment of work that can be delivered by the team within the sprint cycle. Priority is set by the Product Owner, and the PO dictates the order in which stories are delivered by the team.
The Sprint Backlog are those stories that have been committed to by the team for the upcoming or current sprint. In order to qualify to be a sprint backlog candidate stories must have enough detail (meeting the Definition of Ready – DoR) that the team is comfortable estimating the size of the story (story points) and stakeholder input/approvals have been included. The number of stories in the Sprint Backlog are determined by teams capacity built over sprint over sprint, what is also known as their velocity.
Burn Down Chart
The Burn Down Chart is the means by which the Scrum Master, team and other stakeholders keep track of progress throughout the sprint. The ideal chart would have the team incrementally completing stories throughout the sprint and thus “burning down” the Sprint Backlog to land at 0 story points left at the end of the sprint.
Sample Burn Down Chart above – Blue line represents ideal progress, red line represents actual progress
Product Backlog Refinement (PBR)
Backlog Grooming is the process by which the Product Owner gets their stories Sprint Ready. It involves setting the vision, proving the business case, meeting with customers and other stakeholders, conferring with the team, working with UX & visual designers. Care should be taken to get enough detail into stories that the team is clear on what needs to be delivered and why, but not so much detail that analysis paralysis occurs. Grooming sessions with the team should be time-boxed to make sure their time is spent optimally and mostly devoted to getting actual work done delivering items for the current sprint. A typical grooming session lasts for about 2-4 hrs depending on the length of the sprint, and the development team has to make sure that each story meets their DoR as an input to the Sprint, and the acceptance criteria and assumptions meet Definition of Done (DoD) for the final approval of the story.
The Sprint is time-boxed cycle that is 1 – 4 weeks in duration. At the end of the Sprint an increment of the product should be completed and ideally delivered to the customer. Sprint Planning is the session run by the Scrum Master where the team decides how many stories they can take into the upcoming sprint. The team selects stories in priority order set by the Product Owner. A team that has been working together for several sprints or more will have a historic record of how many story points they can take into a sprint. This is referred to as their velocity. Ideally their velocity will increase over time as the team builds. The objective of the sprint planning is to commit stories for the upcoming sprint to the PO, and identify all activities required for the development of the story to meet the DoD.
Daily Standup (Scrum)
The Daily Standup or Scrum is facilitated by the Scrum Master on a daily basis at the same time everyday without fail for the development team. It is time-boxed to only 15 minutes. Each member of the development team comes on time, and answers three questions – what did they work on yesterday, what are they focused on working today and if there are any impediments in their way. Impediments are noted by the Scrum Master and taken to be discussed offline, and are addressed following the standup.
The Retrospective is a crucial ceremony in Scrum that invites Development Team Members to give an honest assessment of their team’s performance in recent sprint. It is facilitated by the Scrum Master, and may or may not include the Product Owner. Some teams may need the Retrospective as a place to discuss issues with the Product Owner and in that case may need them to be excluded to allow for open communication. Team Members each provide a list of the following categories: “Start Doing”; “Stop Doing”; & “Continue Doing”. These may be framed in different ways but basically the conversation should be open and constructive in identifying room for improvement; issues; as well as celebrating successes.
These are the basic components of Scrum. The best way to learn is to practice and each team will grow and modify the techniques to meet their unique group dynamics & development environment. Other good sources are –
Product backlog refinement, or PBR, is an integral component of successful Scrums. This process of continuously reviewing product backlog items, to ensure that teams know exactly what to work on in the sprints, cannot be done without. It keeps the teams and the product owner on track. To understand why PBR is critical, it is necessary to first understand the details of what PBR is, what we expect from it, and the strategic value it provides.
What is PBR?
Product backlog refinement is the process in which the product owner, ScrumMaster, and the development teams review the product backlog items and define the stories that they will need to work on during the immediate sprint. Epics or unclear stories are split apart into smaller stories and are detailed in this process, while unnecessary backlog items are removed. In so doing, the backlog items are analyzed in terms of how much time and work each one will require, and the requirements for each item are clarified. After the PBR session is complete, each story should be valuable and testable.
PBR is conducted in each sprint planning meeting to address the tasks for the immediate sprint. Thus, for each project, PBR is conducted at least as many times as the number of sprints. New Scrum teams, or those with sprints of more than two weeks, may find it useful to conduct more PBR meetings than the number of sprints in their project; additional meetings would be conducted outside of the sprint planning meetings, and these could compose up to ten percent of the teams’ time. The frequency with which PBR should be conducted is due to the volatile nature of Scrum product management. The completion of each sprint reveals more details regarding the product, which results in the need to alter stories — by adding or deleting certain aspects of the stories — and update.
Expectations from PBR
The process of PBR is conducted with the intention of thoroughly prepping development team members about the sprint’s tasks, such that the teams know precisely what to work on and achieve by the end of the sprint. It also is conducted to assist the PO in getting the top-priority backlog items ready for the sprint planning meeting. Essentially, product backlog refinement occurs with the purpose of clarifying each sprint’s tasks and ensuring that they are in sizable chunks that can be accomplished.
Each PBR session is intended to provide team members and the PO with opportunities to update their sprint tasks accordingly, while additional PBR sessions outside of sprint planning meetings enable them to work on detailing and refining a larger number of backlog items.
Vision and strategic value of PBR
Product backlog refinement assists in ensuring progress toward the project’s objectives. The process succeeds in keeping the PO and development teams on track toward the project’s main objectives, as it is a way for the PO, ScrumMaster, and development teams to maintain a clear vision of the sprint tasks, especially in light of product feedback, the emergence of new ideas, and changes in project needs — aspects that can occur throughout each sprint. Scrum product management involves constant shaping of the product, which necessitates redefining the backlog tasks in each sprint. PBR optimizes such redefining of backlog tasks, thereby preventing the PO and teams from losing sight of the work to be completed in each sprint. In so doing, PBR keeps the PO and teams on track during the project.
Not only does PBR keep the PO and development teams on track but it also provides strategic value in that conducting PBR prevents a number of issues from arising later on in the sprint. A main issue that PBR can help the PO and teams to avoid is delivery of stories that do not meet the recipient’s full needs. Without PBR, teams work on stories whose details are not clarified, leading the teams to complete the stories unaware of certain requirements. This results in a loss of time and effort. Another related issue that PBR can make avoidable is a volatile team velocity that results from running ambiguous sprints. If a PO and the development teams choose to forgo PBR, they also risk completing sprints where the stories they worked on were not the most valuable stories. Had a PBR meeting been conducted, the more valuable stories could have been noted and addressed accordingly.
The value and benefits associated with product backlog refinement are large, as are the consequences of forgoing the process. On top of the value it holds, PBR can be easily integrated into each sprint. Therefore, there is little reason to pass over this process that is critical to Scrum success.
Agile is increasingly mentioned as the go-to method for product development, and given the coverage on agile, it appears that there is a consensus that agile is at least viewed in a neutral light, if not favorably. Despite this, there are adamant nay-sayers against agile. For those who are attempting to transition their teams into embracing agile, it can be difficult if a team member is resistant towards agile. This post serves to provide insight into the criticism that some may have towards agile, in order to assist those seeking to convert agile nay-sayers into enthusiasts. For those who hold an unfavorable view of agile, this post will detail the potential of using agile with customer insights to transform products, along with the top agile practices to adopt in order to maximize a product’s reception.Main Criticism Against AgileLack of Structure
A common criticism against agile is the lack of structure, especially in comparison to traditional methods such as waterfall. Indeed, agile is more open-ended and it embraces changes. That is not to be mistaken with chaos, though. Critics may misinterpret the lack of structure to lead to team members working on any number of tasks that may be irrelevant, and that progress cannot be achieved efficiently. Agile, in its lack of linearity and openness to quick changes, induces the opposite effect. It enables more progress to be attained during development, as multiple rounds of testing enable product features’ issues to emerge quickly and to be addressed immediately, resulting in a more complete product.
Rushes Into Development
Some may view the multiple cycles involved in agile to be a “rush” and that it undermines thorough and successful product development. Agile cycles consist of the stages of more traditional methods, but less time is spent on each stage within each sprint. This “rush” into the next stage is precisely what enables agile product development to incorporate so much user feedback into the process – and this incorporation of feedback results in a better product.
Another main criticism against agile is the apparent “agile fever” that is sweeping across businesses and industries in the attempt to benefit from this method. This criticism is not unwarranted, for as is true with anything, too much of a good thing can be detrimental. With agile, it is important not to rush into implementing it merely because everyone else appears to be doing so; it is vital to thoroughly understand agile before adopting it, and even upon adoption it, the process should be tailored to each business individually.
Using Agile With Customer Insights to Transform Products
Agile, contrary to the main criticisms that exist, is an efficient method to transform products into ones that are well-received by the targeted customers. Each sprint in agile product development provides the opportunity to glean and incorporate user feedback into the next sprint. Not only is user feedback allowed to be a major factor in the product’s development, but agile also provides ample opportunity for product issues to emerge and to be addressed on the spot, before the final product is released. Under agile, the product is completed multiple times and assessed as such, allowing for it to be enhanced a number of times more than if another method were used.
Each sprint in agile product development can be viewed as a trial run, wherein user assessment is gleaned and addressed accordingly. Had the product been developed under a method other than agile, user assessment would not be obtained until the final product was released – by which time it would be more costly to fix the issues and to incorporate what users want and need from the product; the product’s reception and success would suffer accordingly.
Top Agile Practices to Adopt
To maximize the potential held by agile product development and customer insights, it is important to emphasize the adoption of certain agile practices, namely continuous integration and design review. Continuous integration of feedback results from, and fuels, constant effort to glean feedback on and enhance the developing product. This is vital in creating a more successful final product that matches or surpasses user expectations. Design review, the other top agile practice to adopt in order to maximize integration of customer insights into the final product, enables teams to review design stories with consideration of the latest product feedback; it poses the opportunity to plan further work on the product with the feedback in mind.
There will continue to exist agile nay-sayers who will not embrace agile, despite the lack of evidence for some of the main criticisms against agile. For those who are swayed by the potential held by agile to incorporate user feedback into the creation of successful products, there exists ample information for them to begin their 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, 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.
Agile coaches must be involved in the client’s Agile process. Those who have the impression that coaching can be done from the sidelines are mistaken, for coaches must get their hands dirty if they want to bring about successful Agile adoption.
To better explain why Agile coaches cannot be observers, I will provide details about the possible mayhem within the Agile landscape, some twisted thoughts about coaching, and the high-level transition plans that Agile coaches should set in motion for their clients.
Mayhem within the Agile landscape
The landscape is rampant with companies trying to transition their teams to Agile while not implementing the method fully. Companies transitioning from a traditional method to Agile face obstacles in the process. Company leaders must fully understand Agile. On top of that, they then must convey the information to their teams and get everyone to coordinate. During the Agile transition, they may encounter issues such as working on too many projects at once, improperly allocating resources, and not forming truly cohesive teams. In certain companies, such transitions are major ones — a situation that increases the difficulty of transitioning to Agile.
These obstacles are such that the move toward Agile likely will not be smooth and successful the first time around. Without Agile coaches to guide them, companies will fumble through trial-and-error projects numerous times before they attain full Agile implementation. Their Agile adoption process will require more time than if they had the assistance of an Agile coach.
Twisted thoughts about Agile coaching
Not any Agile coach will do, however. Companies who decide to enlist the assistance of a coach need help in laying a solid Agile foundation and smoothing their adoption process. In order to provide such assistance, Agile coaches must immerse themselves in the process as if they were part of the company.
Too many Agile coaches, however, are under the impression that coaching consists merely of teaching the company leaders the Agile components. They teach Agile instead of walking the companies through the process as coaches. Few deem it necessary to observe the leaders and teams or to provide insight into what is properly implemented and what needs to be done better. Yet Agile coaches cannot be sideline observers of their clients, because Agile implementation does not come with a guidebook. Each company will have a unique implementation process based on individual dynamics, and coaches need to understand each company and tailor their coaching appropriately.
The Agile coach’s necessary involvement
Agile coaches must coach hands-on. Companies know their transition to Agile would take significant time for them to sort through on their own, and often they want to thoroughly adopt Agile more quickly. Such companies enlist Agile coaches for their seasoned insight and experience, which coaches can provide if they work properly within the company.
Coaches who stand on the sidelines, give advice on the Agile method, and then leave quickly do not assist much toward a successful transition to Agile. They need to remember the reason why the companies sought them out in the first place — to guide them through the Agile implementation and provide pointers along the way. Agile coaches need to understand the companies that they work with, provide insight into how Agile can fit into each company individually, and guide each company through the transition.
Agile coaches can become involved at any stage of the transition process. It depends when a client has deemed it necessary to enlist a coach’s assistance. Ideally, a company would enlist an Agile coach from the beginning to reduce delay.
Agile transition is not a one-size-fits-all proposition; there is not one structured set of rules for the process. To assist companies in attaining the expected outcome of a quick, smooth Agile adoption, coaches should have transition plans tailored to each company. However, coaches can approach this in a general order, by first identifying and addessing the company’s particular issues. For instance, if a company’s team members do not work cohesively, then the coach should guide the leaders to focus on removing the impediments to good teamwork. Coaches must help pinpoint and address issues impeding Agile implementation.
This entails providing on-the-ground assistance in coordinating teams throughout the company to understand and use Agile, defining each company’s process, aligning the entire organization with Agile, and guiding the company to see issues and solutions more quickly.
The key is that Agile coaches need to be part of their clients’ Agile process. When coaches see themselves giving advice without taking time to observe the client’s teams on multiple occasions, that is when they cease to be Agile coaches.
For past couple of months I’ve been working on my latest book on Agile Learning and Knowledge Sharing – and have found a very close association of coaching with building a learning community within an organization. As someone said – “It is hapless without the hopeless, and the worthy for the just cause”, needless to say it is important to look beyond the obvious and dig deep into the realms rather just the facts in order to attain the knowledge required by each individual or a group as a whole.
I’m deeply inspired by the book “The Fifth Discipline” by Peter Senge. Though the book has a total different meaning, cause and inspiration, but it fairly well talks about the elements for building learning communities and where they stems from. As the culture within the organizations develops overtime, and the breed of experience cogs starts to accumulate and a plethora of structure of work is built around the masses – it becomes known where all the knowledge is getting piled up and built.
Knowledge creation is a key element for building the learning community, and Peter and his group talks about following key critical elements within knowledge creation:
This is the area where a disciplined approach to discovery is required, and a development of understanding with a commitment in order to share what’s being learned.Practice
Everyone works towards producing some practical results, and more so the application of energy, tools and efforts applies to all individual who consistently perform the work diligently and get better at it over time.
This is a bridge between research and practice. These are those who help others build skills and capabilities through the use of new methods and tools – in a common lingo development of best practices and processes proven over time through the use of research, discovery and practice.Next, I’ll talk about how to take these three elements within Agile concept and apply.