Updated: Apr 28, 2021
That's the question that was raised recently during a group slack conversation that I was fortunate to be a part of. Among the multitude of responses; answers ranged from:
Throw them at the wall and see what sticks, and
Engineers are often resistant to measuring their work
As a long time practitioner and advocate of Scrum I was not alarmed by these responses, but what I found disheartening among respondents was the undertone of abandonment for the agile framework. If Scrum is ineffective then why are we still using it?
In my 10+ years as a software professional, I’ve seen teams succeed with Scrum and I’ve seen teams struggle. I’ve seen teams embrace the framework with discipline and precision, and I’ve seen Scrum teams succumb to the mindset that Scrum is mired in too much process, too many meetings and Scrum ceremonies that lack any of the hallmarks that support a successful sprint cycle. I’ve seen opportunities squandered and I’ve seen organizations invest tens of thousands into the framework, only to question the effectiveness of Scrum when the framework fails to live up to the expectations.
So why are some teams successful, while others apply the framework in name only? Let’s start by defining a story point.
What is a User Story Point
If you google “what is a user story point” the first definition you get is:
“A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story.” ~ www.visual-paradigm.com
There are two hot button words in this definition, metric and estimate, two things developers and Scrum teams often loathe, especially in organizations new to the framework. And I get it, there are lots of variables that could impact an estimate but if that’s the case, would it not behoove us to talk about these variables rather than shrug it off as an effort in futility?
When we commit to understanding the complete breadth of what contributes to a story point, we develop a broader mindset to story point estimating and we establish a deeper appreciation for the supporting ceremonies and conversations that contribute to a well formed story point.
User Story Review
The term user story is often defined as - informal, lightweight, and high level. Unfortunately, many definitions apply a very simplistic sentiment to user story development and because of this, we often construct user stories with vague requirements and we overlook the conversation around “why”.
Why do we need to build this particular feature and what does success look like?
Furthermore, we often mislabel user stories using vague naming conventions such as “update login page” and unfortunately this type of naming convention often sets a simplistic tone, leading teams to solely focus on what’s written in the informal, lightweight, high level artifact. A common makeup of today’s user story is often represented with a vague description, followed by a few wireframes if you’re lucky and rarely is there any mention of personas, stakeholders or the definition of done.
Yes it’s true that user stories should not be lengthy requirements documents, nor should they be prescriptive and inform the team on how a solution should be implemented; but they do deserve better description and more thought than you find in today’s average story.
Struggling teams often limit dialogue to the technical details and by doing so, they overlook the totality of effort, and this often contributes to user stories that are greatly underestimated and consistently roll over from one sprint to the next. Successful Scrum teams on the other hand use the user story review ceremony as an opportunity to dissect the use case and engage in meaningful conversation; personas, stakeholders, acceptance criteria and usually a goal post to signify to the team that they have met their objective for this particular body of work.
When teams embrace the user story review ceremony, they get to a more realistic number for user story points, they have better dialogue, communication, and intelligent conversations about the work that the team will be committing to (and be held accountable) in a future sprint.
You could argue that this type of approach to user story review creates too much overhead, but what about the overhead that's created when your team is mid-sprint and there’s a strong likelihood that the story in question will roll over once again into the next sprint?
Image credit: https://ascendle.com/
When properly executed, poker planning can be a vehicle for constructive dialogue and thoughtful story points; yet many struggling Scrum teams often relate to poker planning as an exercise equating hours of work to individual story points and often conclude by differing to the point estimate given by the most seasoned member of the team. Story points are often limited to developer effort and exclude the total effort of the entire team of individual contributors. Rarely is this approach successful, yet this is often one of the biggest mistakes that struggling Scrum teams succumb to.
Why is this a problem? It is not uncommon to find that the team member with the most work is QA. In mature QA organizations, QA team members often need to test not only the new feature (being delivered) but they may also need to complete a series of regression tests and update existing automation. Not to mention today’s modern development is distributed across mobile and web and therefore the breadth of testing and effort that must be performed is significantly more involved contributing to a much larger story point.
Estimating user stories is not about equating X number of hours for every X number of story points. Estimating user stories is about equating one body of work relative to a body of work of similar effort from the entire team.
This is where many Scrum teams struggle and learned behaviors begin to emerge and often persist. Successful Scrum teams approach poker planning with a conversational mindset and they adhere to the mathematics of Fibonacci. Collectively they discuss the user story, then apply individual estimates and discuss outlier estimates and inconsistencies. They come to a consensus and apply a point estimate similar to a relative body of work, previously completed for a user story of similar effort.
If you want better estimates from your Scrum team, invest time in thoughtful user stories and develop proper poker planning etiquette including Fibonacci.
Sprint planning is yet another opportunity for teams to align on user story points, yet rarely do teams revisit the story point estimate that was previously agreed to during an earlier user story review. It’s fair to assume that previous point estimates have not changed in the last few weeks, however the adage measure twice cut once still applies.
Struggling teams often overlook this step and it’s possible that a team member may have left the team, or a new team member may have joined. There are a number of variables that could lead to a previously estimated story to change, and before committing to a certain velocity for the next few weeks, align on the most current story points. Successful teams account for these changes and on more than one occasion I’ve seen teams adjust points for a previously estimated story.
Velocity is the team’s benchmark on the consistency of their completed work within a given period of time. It sets a tone for the accomplishments the team is capable of and it also serves as an indicator to the team that they are too ambitious when sprint commitments are consistently missed, or it can serve as a number the team should attempt to exceed when teams consistently hit their target.
Struggling teams often struggle with velocity for many reasons:
Inaccurate Point Estimates: Struggling teams have inaccurate point estimates for many of the reasons stated above, however not correcting these behaviors will only lead to inaccurate velocities that continue to persist until the behavior is corrected.
Failure to Adjust: Struggling teams fail to adjust velocity from the previous sprint and often carry that same velocity through to the current sprint. If your team was unable to hit the velocity from the previous sprint, how is it now possible to hit that same velocity given identical factors? There is nothing wrong with adjusting velocity until consistency can be achieved. Stretch goals and ambition need to be recognized, but struggling teams often do themselves a disservice by setting the bar too high and consistently missing the mark.
Impediments: Impediments can be velocity killers yet rarely do we take into account the impact that impediments have on velocity and on the team. Impediments do occur and they need to be addressed, but it’s also important to recognize that not everything is a fire and tradeoffs do need to be made when impediments surface. User stories must be sacrificed within the current sprint to accommodate for the impediment, and if your impediment has a value of 3 story points, you must understand that 3 story points in the current sprint will be removed and delayed to a future sprint. This exercise helps teams develop consistency and an average velocity that leads to better planning and better outcomes. Know the trade offs before you flood your team with impediments.
"If everything is important, then nothing is." ~ Patrick Lencioni.
Team Member Allocation: No team member can be 100% allocated, yet struggling teams often fail to account for this during sprint planning. Between meetings, time off, administrative support, etc… typical team member availability is around 60% yet we fail to account for these variables during sprint planning. If the concept of team member allocation is new to you, you might look to a Sprint Velocity Calculator to help guide you through team allocation during your team’s next sprint planning.
Daily Stand Up
The daily stand up in today's world of Scrum is often one of rigour; what did I work on yesterday, what am I working on today, and the usual “no blockers” response, and yet this is another missed opportunity to discuss incorrect story point allocation. We are quick to recognize completed user stories, but we often ignore the elephant in the room that will roll over for another sprint.
We inspect what we expect, and if we recognize that an underestimated user story continues to linger in the “in progress” column then perhaps we should be discussing it in more depth. Did we underestimate the back end, the front end, or did we overlook support from the cross functional team whose service we are calling? There are a number of reasons a user story could be underestimated and what better opportunity to discuss than during the daily stand up.
Argued by many as the most important of all ceremonies; the sprint retrospective is more than an opportunity for the team to review:
What went well
What didn’t go so well
What can be improved
What do we want to start doing
What should we stop doing, and
What should we continue doing
Unfortunately many struggling Scrum teams view the retrospective as yet "another meeting" within the framework of Scrum, and the tone is often one of “let's hurry up and get through this, so I can get back to my desk to focus on actual work”.
The retrospective is such a squandered opportunity for struggling teams and yet it is precisely the place for the team to revisit point estimates for the various stories from the most recent sprint.
Why did the team underestimate a particular story and how would the team estimate a similar effort in the future
What went well about the user stories that were estimated correctly
How many impediments did the team encounter and what can we do to better manage this in the future
Do we need to adjust our velocity for the next sprint and if so, why and by how much
Successful teams discuss these items during the retrospective and they take advantage of the time together to improve their cadence, their process, and they create better alignment amongst the team.
One of the best tools for having a productive retrospective is to document the various issues that the team encounters throughout the sprint, and discuss them as a main topic during the retrospective.
So is there an ideal number of user story points? I would argue yes, and that number is different for each team. Teams that are successful with Scrum know their average velocity, they know when to adjust, they know what contributes to a successful story point estimate and they embrace the Scrum framework, the artifacts, the ceremonies and the mindset that the team is constantly learning and evolving.
Successful Scrum teams have the supportive of leadership. A leadership team that recognizes that successful adoption involves more than just sending a few team members to a two day boot camp with the promise of a certification at the end of day two; it involves an organizational commitment from all your stakeholders, not just product and engineering. Scrum has many stakeholders and the likelihood that you aren't affected by something product and engineering is working on is highly unlikely.
Scrum requires patience and an understanding that it takes time for teams and organizations to truly understand and adopt the framework. We do our teams a disservice with the expectation that they should be firing on all cylinders within a handful of newly implemented sprints and we set ourselves up for failure when we take a lackadaisical approach to its adoption. We create an environment of distrust in our teams, distrust in the framework and we quickly begin to explore alternative methodologies destined for a similar demise.
Scrum requires investing in the supporting roles and an appreciation that each role is a contributing member of the team.
Please, please, please avoid the compulsion to assign your lead developer or product owner to the role of Scrum Master.
To do so is an injustice to your Scrum team, the organization, to the framework and more importantly to the person bestowed with the responsibility of doing their “day job” while also facilitating the responsibilities that come with being a seasoned Scrum Master. The scrum guide calls out twelve different functions of a Scrum Master and not one of those functions specifically mentions “facilitates stand up”.
The goal of any polished software team is outcomes over outputs and if your Scrum program is currently struggling, take a step back and evaluate the effectiveness of our investment. Where are the bottlenecks and what are the pain points that your teams are experiencing? You wouldn’t abandon your workout and diet routine if you failed to see immediate results within the first few visits to the gym, so why are we quick to pass judgement on a process that has as many moving parts as Scrum?
About the author
Jim Apodaca is the founder of Apodaca Consulting and an industry professional with over 15 years of experience in the areas of product development, project and operations management. Jim has a leadership background in SaaS start-up and fortune 1000 enterprise organizations and he has lead teams and organizations through various stages growth including the implementation of OKRs, scrum and the development of PMO center of excellence.