A product backlog item, a user story, or any other piece of work is measured in story points, which are a unit of measure for conveying an estimate of the entire effort (or complexity) required to implement it. We assign a point value to each item when estimating with story points. Teams usually utilize a Fibonacci or Fibonacci-like scale of 1,2,3,5,8,13,21, and so on. These points are frequently rolled up as a technique of monitoring velocity (the sum of points for items finished that iteration) and/or capacity planning (the number of points we can fit in an iteration).
Story points appear to be a good idea for a variety of reasons:
The relative method eliminates the need for a ‘date commitment’, so no artificial deadlines.
It is less expensive than traditional estimation.
Collaboration and cross-functional behaviors are encouraged.
You cannot compare teams using different story point definitions.
But there are a few things you may not know about story points:
Story points were not (and have never been) referenced in the Scrum Guide, nor have they been a required component of Scrum.
The eXtreme Programming (XP) initiative gave birth to story points.
They began by estimating in “ideal days” and later, unitless Story Points. – Ron Jeffries is credited with introducing them.
Ron Jeffries, the creator of story points estimation, has a word of caution to anyone using the story points to estimate their work – “beware of using story points, they turn out to have been a bloody mistake.”
Problems with story points:
They can confuse customers.
Within a team, they are wildly inconsistent.
They may promote negative behaviors.
They are a clumsy planning technique that’s full of assumptions
To address some of the above problems, Nick Brown, in his article “Story Pointless,” is proposing some better ways for story estimation/forecasting. He suggests that two key flow metrics be used – Cycle Time and Work Item Age.
The length of time that has passed between when a work item began and when it was completed is known as Cycle Time. Our 85th percentile indicates that we complete 85 percent of our stories in N days or fewer. As a result, we can explain this to consumers and stakeholders by saying, “If we start working on this now, we have an 85% chance of finishing it in N days or fewer.”
If the customer is satisfied with the prediction and we begin work on an item, it is critical that we do not stop there and continue to manage the customer’s expectations.
Work Item Age is the second metric for use to keep a constant focus on flow. This is the time difference (in days) between the start and the present time. This only applies to products that are still being worked on.
We should use this in the Daily Scrum to compare an item’s age to our 85th percentile time, as well as to see where it is in our process.
If the cycle period is about to be ‘breached,’ we need to swarm on an item or break it down as needed. If this isn’t possible, there’s a need to consult with stakeholders to come up with the best solution. Our duty as a Scrum Master / Agile Delivery Manager / Coach would be to help the team comprehend the trade-offs between high WIP age items vs. those closest to completion vs. starting something new.
In the world of software development, estimating when something will be completed is particularly difficult. Our work is primarily in the ‘Complex’ (using Cynefin) domain, where there are “unknown unknowns.” When someone inquires, “When will it be finished?” — because there are so many variables to consider, we can’t give them a single date or number. As a result, rather than approaching the question as deterministic (a single possibility), we approach it as probabilistic (a range of possibilities), so we give the answer with a probabilistic date range instead of a specific date. We also don’t use story points.
In the book, The Wisdom of Teams, Jon Katzenbach and Douglas Smith define a team as “a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” There are some valuable aspects of this definition that are worth discussing. First, note that teams are described here as generally “small.” Keeping a team small (12 or fewer members) allows team members to develop better relationships and communicate more directly.
Second, team members have “complementary skills.” While individual team members may not possess all the skills required to complete a project on their own, the team collectively has the necessary skills. This could mean the team consists of specialists who all own their roles in the project, but agile methods also promote the use of generalizing specialists (multi-skilled individuals who can readily move between roles). Generalizing specialists with cross-functional skills can perform many different tasks on projects and can help smooth resourcing peaks and troughs.
Third, teams are defined as being “committed to a common purpose.” This means team members are aligned with a project goal that supersedes their personal agendas. Teams also share common “performance goals” and a common “approach.” In other words, team members are in alignment (if not always in agreement) as to how the goals will be measured and how the team should go about the work. Finally, there’s the idea that team members “hold themselves mutually accountable.” In other words, the team has shared ownership of the outcome of the project.
Many people have researched how we build high-performing teams, including Carl Larson and Frank LaFasto, authors of the book Teamwork. Larson and LaFasto interviewed a wide range of teams, including the space shuttle Challenger investigation team and executive management teams, and discovered a surprising consistency in the characteristics of effective teams. In their book, the authors explored the eight properties of successful teams and examined priorities in building a high-performance team. The following guidelines are influenced by their research:
Create a shared vision for the team: Doing so enables the team to make faster decisions and builds trust.
Set realistic goals: We should set people up to succeed, not fail, so goals need to be achievable.
Limit team size to 12 or fewer members: Small teams communicate better and can support tacit (unwritten) knowledge.
Build a sense of team identity: Having a team identity helps increase each team member’s loyalty to the team and their support for other team members.
Provide strong leadership: Leaders should be there to point out the way, and then let the team own the mission.
Lyssa Adkins, an author of Coaching Agile Teams, has also explored the concept of a high-performance team and identified the following characteristics of such teams:
They are self-organizing, rather than role- or title-based.
They are empowered to make decisions.
They truly believe that as a team they can solve any problem.
They are committed to team success vs. success at any cost.
The team owns its decisions and commitments.
Trust, vs. fear or anger, motivates them.
They are consensus-driven, with full divergence and then convergence.
And they live in a world of constant constructive disagreement.
Let’s look at these characteristics in more detail. Members of self-organizing, empowered teams are freed from command-and-control management and can use their own knowledge to determine how best to do their job. Empowering teams enables organizations to tap into people’s natural ability to manage complexity. We manage complexity every day, by juggling our work life, home life, e-mails, phone calls, and appointments. Organizations often fail to capitalize on this ability when it comes to executing project tasks, however. Instead of presenting team members with a number of items that have to be accomplished, they present a set of ordered tasks that, in reality, might best be done in a different way. Allowing teams to self-organize enables us to use the individual complexity management skills that we all have.
The recognition that the team is in the best position to organize the project work is liberating and motivating for the team members. People work harder and take more pride in their work when they are recognized as experts in their domain. When self-organizing teams select work items from the queue of waiting work, they have the expertise to choose those items that are not blocked for any reason, that they are capable of doing, and that will bring them toward the iteration goal. This practice alleviates many of the technical blockages seen in push systems where the task list and sequence are imposed on the team.
Thus we need to delegate responsibility for success to the team and allow them to do what is necessary to achieve the goal. This is the “downward serving” or servant leadership model used by agile methods. Instead of a “directing” style, which is a command-and-control approach where instructions are passed from the project manager to team leads down to team members, agile projects take a servant leadership approach, where the project manager or leader shields the team from interruptions, removes impediments, communicates the project vision, and provides support and encouragement.
Using trust (rather than fear or anger) as a driving force in teams’ motivation helps the team in establishing open, honest, and transparent communications. Trust is a key factor in team building and a needed enabler for cooperation. A high-performance team increases trust by building a culture of partnership and shared values. In general, trust-building is a slow process, but it can be accelerated with open interaction and good communication skills. Trust building needs personal knowledge and regular face-to-face interaction, but it also requires empathy, respect, and genuine listening.
Trust along with item 7 (“They are consensus-driven, with full divergence and then convergence”) speaks to establishing a safe environment in which team members debating or arguing over issues is seen as healthy and is encouraged because this practice ultimately leads to better decisions and stronger buy-in to those decisions once they are made. Divergence (the argument and debate) and convergence (the agreement about the solution) increase the team’s commitment.
Item 8 (“High-performance team live in a world of constant constructive disagreement) is related to item 7. Constructive disagreement is vital to really understanding and working out issues. Patric Lencioni, the author of The Five Dysfunctions of a Team, lists the following dysfunctions that damage and limit team performance:
The absence of trust: Team members are unwilling to be vulnerable within the group.
Fear of conflict: The team seeks artificial harmony over constructive, passionate debate.
Lack of commitment: Team members don’t commit to group decisions or simply feign agreement with them.
Avoidance of accountability: Team members duck the responsibility of calling peers on counterproductive behavior or low standards.
Inattention to results: Team members prioritize their individual needs, such as personal success, status, or ego, before team success.
These dysfunctions all stem from avoiding conflict (or constructive disagreement) and not having a safe environment where it is okay to ask questions. Establishing a safe environment for disagreement is key to success; such an environment allows team members to build a strong commitment to decisions. If they have such a commitment when they encounter the inevitable obstacles on a project, rather than returning to management with a list of reasons why something cannot be done, they instead push past the obstacles or find a way around them.
In conclusion, a high-performance team is a small group of people with complementary skills that are united by a common purpose, performance goals, and approach. To be successful, teams should have shared vision, realistic goals, team identity, strong leadership, self-organization, empowerment, belief in their ability to solve problems, commitment to team success, ownership of decisions and commitments, trust, and consensus-driven decision-making with constructive disagreement. These characteristics enable teams to be agile, adaptable, and responsive to change and are essential for achieving high performance.
The strength of any project or company is in getting all the parties involved working together in order to achieve the same goal or vision. In order for this to happen the team needs to be able to access all the information that might be useful in development.
Scrum is a popular agile theory based on the empirical process control theory. Scrum methodology is lightweight and easy to understand, but like all agile methods, it is difficult to master. The methodology documented in the “Scrum framework” is a set of team guidance practices, roles, events, artifacts, and rules to execute projects by. The theory behind Scrum is based on the three pillars of Transparency, Inspection, and Adaption:
Transparency: This pillar involves giving visibility to those responsible for the outcome. The strength of any project or company is in getting all the parties involved working together in order to achieve the same goal or vision. In order for this to happen the team needs to be able to access all the information that might be useful in development. An example of transparency would be creating a common definition of what “done” means, to ensure that all stakeholders are in agreement.
Another aspect of transparency is related to the other two pillars. It is very difficult to Inspect something that isn’t visible. In other words, you can’t solve a problem if you don’t know what it is. Having transparency in the organization as to where things aren’t running perfectly — without assigning blame — gives the entire organization a competitive advantage, as they can then address those issues and become faster, better, and more valuable.
Inspection: This pillar involves timely checks on how well a project is progressing towards its goals, looking for problematic deviations or differences from the goal.
An inspection happens both per iteration during retrospectives and daily during the daily scrum. Healthy inspection habits help the team and organization critically view their work and processes and see if there is anywhere the team/organization could improve. This is where transparency across the organization and within the team is important. Without that transparency, it is very difficult to inspect.
A key aspect of inspection in Scrum is that it is approached completely in a non-judgemental, non-blaming way. We aren’t interested in finding out whose fault it is, what we are interested in is finding out what we can do with this now, what have we learned and how we can do better next time
Adaption: This pillar involves adjusting a process to minimize further issues if an inspection shows a problem or undesirable trend.
It’s not enough to just notice the problems or opportunities, the team needs to be empowered to make the changes necessary in order to either fix the problem or experiment with an opportunity. Scrum fosters a “fail fast, fail often” approach. This helps the teams to uncover any issues and address them quickly.
Another aspect of adaption is that during development oftentimes things change — new priorities, a crisis, a change of leadership, downsizing or upsizing, world events, or a market disruptor. Any number of things can dramatically change the work that needs to be done. Traditional teams, who have all the work planned up ahead, will have a hard time adapting to the new reality. They will have to go through change requests, budget negotiations, and new contracts. Teams working with the scrum framework have the benefit of being able to adapt to the new situation and deliver a valuable, relevant product to the client, faster. No contracting, no change requests, just a group of people working together to achieve a common goal.
For Scrum to be effective, each of these pillars must stand and be supported – one without the others greatly deters the effectiveness of Scrum implementation.
The first time I experienced a significant change, I was ten, and my home country was falling apart. The year was 1991 and the country that gave the world the first human in space – the USSR – was quickly sliding into oblivion. At the time, I was too young to fully comprehend the consequences of undergoing change, but not even my parents understood how the collapse of the “evil empire” would affect us all. Almost a decade of hardship ensued, but fortunately, we all survived.
The next significant change for me happened in 1996 when I, under pressure from my teacher, transferred to a different high school. This time the change was deliberate, but still, it was terrifying and uncomfortable. My parents nor I could predict the consequences, and instead of being one of the top students in my old school, I became just one of the many. While I struggled to adjust to much higher academic standards, I was invigorated by all smart and exciting people surrounding me. It was hard, but after graduating in the top 15 of the class, I was very grateful to my teacher for encouraging me to switch high schools.
“There is nothing permanent except change.” – Heraclitus
Then in 2003, after a few turbulent and indecisive years, I undertook the most significant change in my life – I moved to the United States. This time around, I was not scared, as it all felt like a big adventure, and I was extremely excited to be a part of it. Nonetheless, it took me years to adapt: first through thecollege, then through my early career in tech and education, and then through learning how to be American. For a while, I hated driving in American cities; I was constantly freezing from AC in every restaurant that I went to; I struggled to identify various American accents and misused countless English words; I couldn’t appreciate or understand American humor; I hated cilantro, and I was clueless about American politics. Once again, I managed and even learned how to make America my home.
Fast forward to 2017, after graduating from 2 universities, working for three different companies, changing five addresses, visiting 20 different states, and meeting many amazing people along the way, I was hungry for change again. In May 2017, I quit my job, packed a suitcase, and moved to Europe. Only this time, no matter how hard I tried to convince myself that this was just another adventure, it felt more like switching high schools again. It felt very uncomfortable. I barely knew anyone in Berlin and I couldn’t speak any German. I only had ten years of professional experience in the US and a resume I could send out to a bunch of companies in Berlin in the hopes that something matching my skills would transpire. Once again, it took me a little while to adapt to the change (and I’m still adjusting). Yet, now, after 2.5 years living in Germany, after switching two addresses, working for two companies, and visiting 13 different countries in Europe, I am hungry for a change again. Now that I can understand some German and as I’m starting to have more days where I feel like I’m in control vs. the days where I have no clue what is going on around me, I’m willing to pack my bags and leave everything behind and move once again? Have I become a change junky? Or is there something else at play?
