Most people are familiar with the 4x4 matrix of urgency and importance that Steven Covey popularized. (Or actually misappropriated from President Eisenhower).
source: Wikipedia
Although it's true that the majority of high growth stories do include a lot of flexibility, agility, and adaptiveness, that doesn't mean that planning is worthless. Eisenhower quipped that “Plans are worthless, but planning is everything."What's most valuable in planning is being proactive--to prevent preventable crises. And if you really are going quickly, it feels like a car chase already.
How prioritizing during a rapid growth phase feels
Like cash flow crunches. The loss of an important resource. A consistent source of sales.
For example, to help prevent cash flow crises around bills for software and tools that I use in my own business, I realized I can buy annual or lifetime plans. Moreover, I can keep a cash reserve for multiple years' worth of using the tools. This way, I guarantee I'll have the option of being in this business for a much longer time horizon.
It helps shift my own focus from an early stage mentality of "low monthly run rate" which made sense as I validated different business models--to one of an efficiently run business. It also means that I eliminate the occasional surprises around not having enough cash to cover this or that bill.
Note: this is an internal change in my business only. It gives me a good amount of flexibility. All it takes is setting up a business savings account and transferring over financial buffer, so that I can sleep easy at night. In short, I am eliminating a whole category of problem in my own business with this one small tweak.
In his classic 7 Habits of Highly Effective People, Steven Covey shared a quantitative benchmark around for highly effective individuals and organizations (based on his research and work with them):
Source: Steven Covey
As a matter of habit and culture, notice that proactive businesses spend the overwhelming majority of time in Quandrant II. The important and not urgent. Such as coming up with contingency plans and being proactive, without necessarily tying yourself down and committing unnecessarily before you know what you need to.
In the example above, I still have the option to raid the financial buffer. But then I am deliberately changing my decision.
Interestingly, for people who aren't effective the numbers more or less reverse on average. Most of their time is spent doing things of low importance: quadrants III and IV. This crowds out the time needed to do quadrant 2 work, namely important but not urgent work.
Inadvertently, I fell into that trap myself.
While running an agile and adaptive process--without any real external or existential threats--it was easy to just ignore the need to be proactive. If we were honest with ourselves, most of what we did was neither important nor urgent. And it showed on the bottom line unfortunately, i.e. a team spending 2 and a half years to redevelop a product that ultimately didn't sell much anyway. Most people have some kind of a similar story.
In practice, we only really planned one sprint at a time. And that was good enough for us. Over time, I habituated my stakeholders at the time to this pattern. And allowed myself to fall into it, too. Which wasn't healthy. This was the type of product that can't just be rolled out via the internet or directly. I had good reasons to be suspicious of committing to anything beyond one sprint. If we did commit to anything, the team would need to replan everything a sprint later.
In a way, lack of longer term planning paradoxically helped in this context. Most of the volatility around the work was in the latest news on their side. Even though we knew we needed a longer block of time to get to a truly releasable unit of work, at the end of every sprint I'd hear about a new business priority--before we actually released anything.
When confronted with the need for a plan, I mutinied.
I was pretty vocal about being adaptive, later when asked to provide detailed plans, I locked up. I had forgotten what that meant. I wanted the team to be self organizing, and to be left to our own devices. But, something bothered me.
Begrudgingly, I started to assemble bits and pieces and looked through other examples in the company of "good plans" submitted by other managers. And I realized that thinking through things in more detail was helpful, especially once new products or offerings are largely validated. I'd place small details in a larger context, so that the medium term plan was internally consistent, while still leaving myself the ability to back out easily.
But planning itself is good.
For all the trash-talking about "big planning up front", I think it's worth pointing out that in an agile and scrum context, I've never heard anyone claim that planning itself is bad.
In the agile manifesto, the signatories stress they value people over process. But planning is ideally done in a way that takes into account everyone's needs and opinions. Ultimately agile values the team's need to self organize. And that includes planning, if that's what the team needs. Or what a number of teams need to ship their work.
The main reason I've found planning helpful is to realign details around priorities. If you have a large enough team, there is a car chase of details coming at you in any given moment. Being clear on the priorities and knowing how to apply them is where a purely adaptive process breaks down.
I was afraid making plans would be constraining. And only after a while, I realized that it's the proactiveness in planning that was most valuable. Not the plan itself. The plan itself is just evidence of having been proactive.
It is dangerous to use a plan as an organizational commitment device, as that shut down the ability to respond appropriately as new learnings came up. But other than that, there is a time and place for a thought through plan for a team in "execution mode" as they're going to market.
Key Takeaways
Even though high growth requires you to be highly flexible, planning is still a high value activity.
Ideally, you want to aim for spending 65-80% of your time and resources on high importance and low urgency tasks, even as you validate new business ideas.
As a team matures, there will be a longer time horizon of planning ahead, especially if it isn't possible to actually release at the end of every sprint.
Quite often, an ambition to innovate is paired with an unwillingness to change.
Usually, the latter isn't conscious. But it blocks you from finishing or shipping anything.
It can be quite subtle. In how people speak or collaborate. In pushing back. In sub-par levels of trust.
It might seem obvious at the face of it. Yet, it's probably a common issue companies face when trying to become more innovative.
So before trying to convince anyone about a new product, you might be better off trying to introduce a smaller change of some sort, and seeing where the pushback comes from. And where the fault-lines actually lie. Even though it will create a conflict of sorts, it will highlight what you are up against.
Key takeaways
An ambition to innovate is often paired with an unwillingness to change.
Introduce a small change to test how a culture will deal with a bigger innovation.
One of the common anti-patterns which comes from a more traditional project management toolbox is estimating work time. This estimate is later used as a tool to hold employees accountable. To help managers steer the ship, while making sure that utilization stays high. In particular, the measuring stick for good management is that employees are efficient. Over time, employees take less and less time to do a particular type of task.
Call me crazy, but this feels short-sighted to me.
If you are looking improving output and velocity of work (as opposed to employee efficiency) it goes up significantly when you have a solid team dynamic. Where people reach out and help one another, especially if they have different skill sets required to ship a particular feature. This a classic case of conventional management wisdom not tying true causes and effects together.
Ultimately what you care about is finished work. And finished work comes about quickly when a good team dynamic exists, not when individuals are efficient. To be blunt, this comes down to peer pressure dynamics among team members. For a team to work, they need to know what to expect of each other.
This is most obvious in team ball sports.
Any given player needs to pay attention to what everyone else on the court is doing, in order to figure out where to go next. Yes there is a coach on the sidelines, and a captain on the court, but the responsibility rests with the individual.
As the game is playing, could you imagine the coach getting off the bench and running after every player with a stopwatch? Telling them--one after another--to run faster? Anyone who the coach wouldn't be yelling at would slow down most likely. Because he's not getting grief from the coach, so why should he care? This might be more acceptable during practices, but even then, it takes away agency from the employee. And emotional skin in the game.
If you start measuring and tracking individual employee output:
You send a pretty clear message that the team doesn't matter as much as what each employee does
Success and failure rest at the individual level, how much they do relative to what their manager expects of them.
The responsibility for finishing work lays on the manager's/coach's shoulders, and more importantly, doesn't lay on the employee's.
Maybe that's acceptable, and you want the extra control, but usually this will reduce your output. Because the motivation lies solely in the relationship between the employee and the manager. A hub-and-spoke dynamic among a group of people. Not a real team.
Speaking for myself, adding elements of control doesn't feel like it addresses the real issue of people not being self-motivated to work as a real team. It was kind of like buying additional dumbbells or books when wanting to shed a few kilos, like Keith Cunningham points out. It's helpful to have a one new pair, but buying 100x more dumbbells on its own won't burn the fat that much faster.
The root of the problem lies elsewhere: a misaligned team dynamic leading to a lack of individual motivation in the form of manager reprisal.
In contrast, if a player consistently gets the ball and fumbles with it or misses shots on goal, the team won't trust him. That's much more powerful motivator. They understand the consequences (to others) of dropping the ball on any given task.
Conversely, if there are a few good players who trust they can pass the ball to one another and to move their play forward, then things start to happen. Having a team dynamic where everyone chips in matters. Where people know who they can turn to if needed. So they're implicitly clear on priorities, as they enforce them from one another.
Or if you do have a star player, at least the team self-organizes around helping that star contribute significantly on the playing field.
How does overemphasizing work time play out quantitatively?
In scenarios requiring serial processing of work to ship something, like for example a software feature, you naturally start to observe bottlenecks. In particular, a lot of partially finished but unreleased work lies in the "wait states". The amount of time a given piece of work lies in between BA, development, and QA usually exceeds the amount of actual work time spent on it.
Here's a case study. Same time, same year, same product, same technology stack:
aggregate work time vs. aggregate elapsed time for all stories
This was a team that I ran when developing a new product. And what I'm showing here is pretty common. Few delivery people can overcome their "cringe factor". To figure out how much flab there is in a delivery process. In this case above, the aggregate elapsed time was over 3x longer than the work time.
Let's say we achieve a nearly impossible feat: halve the amount of developer work time without reducing the rate at which features were completed. All that would mean is that the purple bar in the stack above would be smaller. But the overall elapsed time wouldn't budge. The story would just wait longer for QA to be able to look at it.
Or halve the QA time required without reducing quality and rate of bug discovery. That would reduce the size of the gold bar. Which is admittedly a win at the story level. Because the elapsed time to the end of QA would go down.
But then you have the next step out: release elapsed time.
How much time elapses in between when all of the stories are QAed and the release goes out the door? If you don't have a continuous delivery pipeline, it could be weeks. So it doesn't matter if QA or dev go 20% faster, because the product won't end up in the client's hands until the product is released.
In practice all features are released together anyway. So even this pinkish elapsed time stack would need to be much taller when you count the time to release.
Key Takeaways
Increasing control doesn't help a team be more efficient, if the team members aren't motivated to collaborate.
Peer pressure similar to that in ball sports is a good model for how successful teams work together.
Strong-arming team members into finishing their work faster usually won't impact the "elapsed time" before the features/product goes out to market.
Came across a wonderful article on medium.com by Jack Skeels. The starting point is Jack bemoaning that HBR is now singing the praises of Agile at Scale (re-dubbed "Agile as Anything Management Wants"). According to him, the actual results of agile are significantly below what is promised. Most companies applying agile focus on process, because that's how they think they'll get efficiency gains. But they miss key subtle points underlying the whole thing. Like moving away from digital taylorism. And towards team self-management.
Management can easily kill agile if they don't understand how it really works
Tons of insight like the following:
In fact, probably the key metric you should use to judge your Agile implementation is how differently you manage and how many fewer managers you need.
During the last couple of years, I’ve used a “Team Ratio” calculator with dozens of companies…how many managers and leads versus team members? This is an aggregate “span of control” measure that reveals how flat your organization is. If you do the calculation, a ratio of greater that 1:8 means you’re flat, and likely have a really good culture, velocity and quality.
Having a good culture, velocity, and quality...where do I sign?
Again, this post doesn't really do the original post justice. It's one I've already gone back to a few times.
Last night, I went to a local meetup where we played Legos. It was an event organised by Krzysztof Niewinski. In particular, it was a simulation workshop of large scale product development using alternative organizational structures. But there were lots of colored bricks involved. And the specs were pictures of the end products that needed to be built.
Without getting into too much detail, we covered 3 alternatives with the same group of 20 something people: component teams, cross functional teams of specialists, and finally "T-shaped" interdisciplinary teams where everyone could do everything. In short, we were experimenting with output using alternative ways of working. Each round took roughly 10 minutes.
Here's what happened
In the first round, we had specialized component teams each dedicated to working with only two different lego colors, a supply team, an integration team, a quality team, and 8 different product managers who wandered from table to table. Sound familiar? Kind of like a massive construction site with lots of project managers. Or in a large company developing and installing software. Most of the building teams sat around doing very little in practice. There were lots of bottlenecks and confusion around getting supplies and exact requirements. I had a chance to engage in chitchat with my table mates. And a stressed out senior executive that walked around and yelled at anyone for not doing anything.
The second round, we continued to have individual performers who were specialists, but they worked together, which resulted in a lean assembly line. The time required to first output went down almost 50%. But there was less top down control. And more legos on the table, relative to the previous round.
And finally--the last round--everyone pitched in and contributed how they could. There were still some constraints, in that people working outside of their expertise could only use their left hand. Despite that, it only took a minute to get the first outcome, so almost 9 times faster. But there were lots of extraneous legos on the table. It was lots of fun, and it was a very tactile learning experience for everyone who pitched in. Just like kindergarten.
What does this mean
This boils down to control, profitability, and speed. This is just as true for startups as it is for large companies. Most of the conflicts among co-founding teams boil down to differences how founders value control and money, according to Harvard professor and researcher Noam Wasserman in Founders' Dilemmas. In big companies, any larger product development program will implictly or explicitly make a call on these three, based on how the work is organized. It depends on what you optimize for, as Krzysztof the facilitator pointed out.
The construction site was optimized for control, especially of costs. There were enough people to do the work, and enough legos could be procured if you were willing to wait. But the level of resource scarcity locked up the system, relatively speaking. And it took a long time to finish anything.
The assembly line required a slightly larger up front investment but the speed at which things happened increased dramatically. Even though the constraints on each individual were exactly the same. As an expert in yellow and green bricks, I was still only allowed to touch these, even though the configuration was completely different.
The kindergarten required even less top down control and more resources, as well as trust that the teams will get on with it. There was be a higher use of resources (lego blocks laying on the table). At any given moment, you won't know exactly what is going on, because everyone is contributing and collaborating. The teams were releasing stuff like crazy. So at that point, does it really matter that you need a bit more money up front? If they are releasing stuff so quickly, presumably this translates into revenue, which keeps the kindergarten afloat and then some.
Choosing the metaphor works that best for your company
The way you organize the work matters. And it feeds into culture. Larman said "Culture follows structure". In a software context, it means you want to allow for chaos and experimentation. And not really just squeezing features out of development teams.
As a company scales from a successful startup to a larger company, the trick is to keep enough of that "kindergarten juice" in the culture and in how the work is organized, in order to allow your company to continue innovating. If the emphasis on control changes as a product matures, you can introduce more of that as needed. But do so consciously, and watch your output and outcomes like a hawk.
By micromanaging the process, even as an assembly line in a feature factory, you're still missing out on pretty big upside (assuming you care about having lots of new products released).
That said, even a kindergarten needs boundaries. So that the teams don't cut corners in quality for example. That's kind of the point. There are a handful of non-negotiables around safety, health, and security in a kindergarten, and everything else is optimized for discovery.
So for a bunch of interested strangers on a random school night, who dug into a few alternative structures and held everything else constant, it was clear that there could be very large differences at play. 14x faster, not 14% faster. These would be results any agile or digital transformation program would love to achieve. That said, it wasn't clear if these differences came from structure only, or the culture around it. And if culture is involved, that could be what's preventing the massive change in the first place.
Key Takeaways
The way you organize work matters, and it feeds into the culture, particularly in a larger company.
By organizing work, you will be making choices about tradeoffs among variables that matter.
Control, in particular, seems to be inversely related with learning and speed.
Following up on the slightly longer analysis of overfocussing on output and velocity, I think there are a few things that are overlooked with a pure velocity based model. Most of them have been known for decades in the software industry. They are squishy.
It's essentially a Taylorist factory where most of the interest is in efficiency, and not on outcomes. by Taylorist, I mean Frederick Winslow Taylor. In fact, Kanban originally came from manufacturing. Cost accounting is the beginning of the imposition of a Taylorist model, to describe something more nuanced than what you see in a factory. (please comment and say why if you disagree). By using velocity as a yardstick, you pervert velocity's purpose and dilute its usefulness.
As per PeopleWareby Tom DeMarco in 1987, most new technology development problems are actually people problems, either on the product development team, or with respect to the customers.
Outputs are assumed to be linear. This is patently not true for knowledge work. Even in 1975 at the time of the Mythical Man Month, it was already acknowledged that adding people tactically is a major blunder in the context of creative work.
More recently, I've fascinated by psychological safety in the team as articulated by Amy Edmonson as an underlying factor influencing actual performance.
At its core, companies care about being able to release quickly. Velocity and story points are just one way to get at what's happening and why it's taking so long. But it's essentially an internal process. At some level, it's just bureaucracy created to manage product creation...on its own usually not valuable to customers.. So in and of themselves, if the teams provide value and can show they are doing so, then velocity doesn't matter.
Recently I had an interesting call with a senior QA leader. He reached out to me He wanted to get a better sense of how his people are doing, both as a functional unit and individually. Primarily, I suspect he wanted to be proactive, and have some kind of a numerical early warning system in place, which he could cross-reference with common sense and qualitative input he got elsewhere.
As we spoke, he kept using the term "velocity" initially; however, it became clear that he meant velocity in a much looser sense than the typical iterative scrum/agile sense. It doesn't really work for what he wanted to achieve.
Here's what I mean:
Core metrics to baseline progress iteratively
What is velocity anyway?
Velocity itself is first and foremost a team output metric, not an individual one. It is a measure of story points completed over a unit of elapsed time.
It gives visibility on whether the product development team is functioning effectively--as a system for generating new features. In this context, new features are what the customer is expected to value most, so we track only that. It is not an efficiency measure, and shouldn't be confused for one. Traditionally this approach came from a software development environment, but can be applied anywhere there is significant complexity and thought required. Knowledge work.
These story points are the primary "raw material" to generate estimates relative to a goal or target date. Once you have a sense of:
who you're building it for and why
what you want to build, i.e. the actual stories defined
and you have estimated the stories using story points
When the product or project work starts, you keep track of how many story points are completed over time. You use to improve future planning. Usually this works in "sprints", which are predetermined lengths of time, as a way to plan and track progress. For example, in the popular flavor of agile called scrum, these will typically last 1-4 weeks.
Realized velocity
Let's use 2 weeks as an example. The newly formed team has started working on a new product or project. The backlog of items is defined and estimated for the absolute "must have" features.
At this point, if you're being completely transparent, you don't know how fast the team will actually go. You can also negotiate what exactly is "must have" to help reduce the time required (less work, done faster). And ideally you'll also all agree on a quality standard that everyone is ok with--which will also have schedule implications (higher bar takes more time per feature on average). So your initial realized velocity/sprint is 0, and you have a guess as to what the expected velocity will be.
You agree (with the team) which stories will be accomplished in the first sprint. And after 2 weeks, you sit down with the team, and compare what actually happened with what you'd hope would happen. At this early stage, there are likely to be a lot of learning outcomes in general, as it's a new effort. But among other things, you can add up the story points completed by the team. This is your first realized velocity.
Expected velocity
After 3 sprints, you should start to see some kind of a trend to emerge in terms of an average velocity. Sometimes it's worth giving the team the benefit of the doubt, as they might pick up the pace once they get their collective heads around what needs to be done.
Usually this number will be significantly different than your expected velocity for the dates you'd like to hit. If you calculate the total story points needed for the "must have" initial release, and divide it by the realized velocity so far. To simplify the thought process, assume it will stay fixed.
This gives you a sense of how many sprints of work will be needed to hit that final date. Usually, there will be a gap between what's happening vs. what's expected. It's best to know this as early as possible. In fact, this transparency is one of agile's strengths. It's difficult to sugarcoat reality, if you see what is being delivered. Moreover, you also see how many initially estimated story points of cognitive effort were realized.
Warning: This type of analysis can cause some healthy consternation and discussion. This is intended. Using this performance data, you can re-prioritize, change resourcing levels, change scope, or whatever else you think might help the team at that stage.
Expected velocity is the ideal pace you'd like to keep, in order to hit your business goals. Often, in more traditional environments, this will be expressed in terms of a target release date. But it can also be in other forms, depending on what's actually important to the business as a whole.
The core difference between realized and expected velocities is their time orientation. The former measures the velocity trend in the recent past. The latter is more of a business requirement, translated into a number. Expected velocity is a practical way to "have a relationship with your target date". This is a metric which translates longer term expectations into an early warning system checked regularly. When compared to your realized velocity, you'll know whether or not your teams are going too slow to hit your dates.
Cycle time
Cycle time comes from a lean background. It's a measure of how long it takes to build one unit of output. In practical terms, it's a measurement of the elapsed time from the start to the end of your production process.
= time(end of process) - time(start of process)
It includes both the actual time spent working by the team, but also all of the wait time in between steps of the process.
Unlike story points, the unit of measurement is time. This is probably cycle time's greatest strength. Time can be subject to arithmetic, statistics like mean and standard deviation, even compared across various aggregations (e.g. among QA team members). It's also less subjective, as there is not estimation required up front. It's just measured continuously. It gives you a sense of what's been happening. And how healthy your process is.
Now for the downsides. Cycle time implicitly assumes:
that the units of output are pretty standard, uniform, and therefore of similar size
when aggregated, that there is no difference between types of work. For example, building new features and fixing bugs in already built features doesn't take the same amount of time.
that there is no goal. It only measures efficiency not effectiveness
Cycle time works well, as a metric, in software for two scenarios:
When stories aren't estimated but just all broken down to be a maximum expected length of 2 days per story for example.
When working on maintenance development, where general process monitoring is needed so that extremes can be investigated but where time pressures tend to be issue & person specific and not team-wide
Takt Time
Takt time operates within a similar framework to that of cycle time. However, instead of measuring what has been happening, it's used to quantify expectations so that they can be continuously monitored.
In a nutshell, takt time measures the slowest expected rate at which you need to complete production processes in order to meet customer demand. It's calculated as
=net production time / total output needed by customer
There are a few numerical examples over here, if you want to take a peek.
Anyhoo, there are a number of really helpful attributes of takt time. It expresses expectations numerically, in terms of how much time should be spent on each item in order to hit a target output. For example, if takt time is 10 minutes, evety 10 minutes you should be pushing out another unit. If you are faster, great! If not, you need to troubleshoot and improve your production process, resources, or context.
The "total output needed by customer" can be measured in just units, e.g. number of stories. This way you don't need estimation and estimation won't introduce subjective bias.
Like expected velocity, it gives the team a number to help establish an operational relationship with a longer term goal or target (that has business meaning). In the moment.
Isn't this all a bit abstract and self-referential?
Yes. It is.
The primary measure of progress in an agile framework is "working software". Or to be more general, demonstrably completed work. It's demoed for everyone to see and comment, and should be done in a generic way so that anyone can participate (i.e. not only people with PhDs in Computer Science). Anyone should be able to see the new features working.
That said, not everything is software. And not all software has a user interface. So it's a bit harder to apply this, particularly in the early days of a new product.
In that case, you can use these metrics to monitor effectiveness and efficiency. You can hold both yourself and the team accountable. You have a numerical framework to deliberate with stakeholders, one that can be checked at any given moment, where you don't need to "check with the team" every time someone wants an update. And like the senior QA manager above, you can use this as a proactive early warning system. If one of a number of efforts is going off the rails, and you oversee a number of them, you'd naturally want some way of knowing that something is off.
So that's the menu. Which one to choose?
It depends where you are in your efforts, how much time you want to spend on estimation itself, and how much you need to make comparisons.
Where you are in your efforts:
Early on in a project, you have a lot of unknowns. They tend to be interdependent. For example, in order to give a date estimate, you need to agree on what you're building, and how you're building it. That might depend on the market segmentation or main business goals you want to achieve, which also might need to be negotiated. And if you tweak any one of these, all the rest are also affected.
At this point, if you add technical estimation with story points for granular tasks the mix, you expose even more uncertainty to the whole thing. You might be better off delaying story point estimation. And just use cycle time until you have a clearer picture. This way, you maximize the team's time on delivering actual work, rather than on estimation under conditions of high uncertainty, and both business and technical complexity.
Once you get to a stable team and vision and roughly stable scope, it might be worth doing some estimation and prioritization of the bigger epics. Follow this with the breakdown (into stories) and estimation of the highest priority epic or two. If your initial scope is very large, you'll spend a lot of time estimating something you don't really understand very well yet (yet another reason to be deliberate and precise with your initial release).
How much time you want to spend on estimation & monitoring:
This is a more general question about the ratio of time spent doing vs. monitoring the work. Estimation is a tool to help you monitor and measure the work. Ideally, it's good to do some estimation, so that you can slot in work tactically. In particular, it's most useful when considering the business value generated and comparing it to the amount of work required to complete it.
But estimating out a year's worth of work, especially if there are no releases to customers during that entire period--that's a notch short of madness. Ideally your releases should be tight and getting feedback both from individual customers and also the market as whole.
How much you need to make comparisons:
Like in the example opening this blog post, if you want to measure and compare individual or team efficiency, then cycle time is easily comparable. This is because the "denominator" is the same in all cases: elapsed time:
You can compare cycle time across various team members, ideally if they are doing similar work, for example QA.
Also you'd be able to compute averages to compare between teams, i.e. QA across different teams.
Standard deviation in cycle time can also be useful to figure out what is truly exceptional, so that you diagnose and troubleshoot (if bad) or repeat (if good)
Next steps
That should hopefully give you enough to get started. The next step is choosing which is most relevant for you, and figuring out how to gather the raw data from internal company systems. Ideally, this is done automatically & behind the scenes using software, so that your teams don't need to enter data manually, esp. time spent.
Key Takeaways
Velocity is a team based output metric that tracks story points completed over time.
Estimation can improve accountability and prioritization, but it costs time and is subject to bias.
Keep customer facing releases small, as this will improve your accuracy and estimate variability.
