Agile Team Velocity and Forecasting

A long while back I wrote an article about “Increasing Velocity vs. Stable Velocity“. In that I listed a catalog of improvements that once done, could help make your sprint velocity stable. Of course the full list would probably never be realized as it’s unlikely teams would do everything. The reason I created the list was to give visibility of the many things an agile team could try. For some people, the list really wouldn’t have helped. Always easy to tell people what they could do but finding reasons and value for doing it is sometimes hard.

I wish here to talk about velocity and the business. Businesses have a tough time keeping their many shareholders and/or stakeholders happy with continuous growth and prosperity. One thing that makes all these people happy, or at least stops them from lynching the execs, is for the business to predict when things will happen with some accuracy. If you’re a software product company or a digital product company, the people you count on for this are your agile teams. The Product Owner manages the business aspects of sprint work while the development team manages the customer solutions. Combined into one agile team, the product owner and development team forecast what they’ll deliver anywhere between 0 to 12 months. This forecast is based on several factors but a key component will be the team’s past track record for delivery, their velocity.


Velocity is simply the average amount of work one team can successfully complete in one sprint. For most teams, this may take a few sprints to stabilize as the team finds itself through the stages of formation.

Velocity sits at the team level and does not translate to individuals on the team. If a team of 5 has a velocity of 40, adding another person doesn’t mean their velocity goes to 48. If the team’s velocity is 40 story points per sprint and a new person is added to the team, the team’s velocity is more likely to fall in the near term rather than rise. This is due to the disruption the new person causes in the team, needing mentoring, learning how to do things the “team’s” way, and the change in group dynamics (see stages of group development). So keep it simple and use velocity for the team.

The product owner

The product owner represents both the customer and the business within the agile team. It is the product owner who’s held accountable or at least responsible for getting the most valuable product features into the hands of the agile development team at the right time. They do this to meet both delivery (business) and customer demands. It’s the agile development team’s responsibility to match their forecasts with actual deliveries, scaled appropriately from near term (sprint) to longer term (release). All this needs to happen with regularity. All this can fail if the underlying forecasts are unreliable. The agile team’s velocity is the most reliable measure used during forecasting.

The single wringable neck

It often falls upon the product owner to meet promised delivery dates. This is strange because it’s not the product owner doing the work. The product owner relies on the development team to deliver. The product owner needs to manage business expectations once an agile release is in flight. This happens regardless of the reliability of the forecasts made by the team. However, the amount of effort and stress associated with managing these expectations can be mitigated if there’s a solid foundation to base initial forecasts on. The solid foundation starts with a predictable team velocity. Once a predictable velocity exists, product owners can begin challenging the agile team to achieve degrees of accuracy in their forecasts & estimates. For example, the product owner and development team might set planning goals as:

  • Get 85% or better accuracy between 0-6 weeks (sprints)
  • Get 60% – 70% accuracy up to 3 months (release)
  • Get 50% accuracy 3 – 6 months (release/future release)

Make success possible yet challenging

It may be the agile team has an unpredictable velocity, especially common with new teams. Asking a team to have an estimation accuracy of 90% for a two-three sprint window when the development team is barely at 35% is asking for failure. Instead if the team is at 35% accuracy, challenge them to achieve 45% within the next two sprints. But simply challenging the development team won’t be enough by itself, you’ll need to work with their Scrum Master to change the team’s current processes. This often means making backlog grooming sessions better.

The backlog

The product backlog is an example of a combining longer term strategic planning with near term tactical planning in one convenient place. The product backlog epitomizes the concept of Just In Time (JIT) planning. The product owner owns the product backlog and they, along with the development team, need to continuously maintain it. The product backlog is prioritized from top to bottom. It’s very common to think of the backlog as an iceberg with 3 distinct layers. The top layer is the bit of the iceberg that is above water, is the sprint ready layer. User stories here are the most refined and best understood. The product owner desires these stories to be the most accurately estimated to make sprint commitments viable. One grooming goal therefore is to get user stories to the highest state of readiness or ‘sprint ready‘.

The middle layer is populated with stories that are in planned releases including the current release but are generally less well understood. These stories are estimated but will likely be split into stories sized to fit within the sprint time box. As stories are split and new understandings are reached, they are re-estimated. Stories from the Release layer are feed into the Sprint layer as openings appear, based on priorities. This is a continuous process. A second goal of backlog grooming is to split stories down to a size that can be completed (Done) within the sprint time box.

The bottom layer but no less important are the stories for Future Releases. These stories might represent new feature or new products. These stories are the least understood and often are more speculative in nature. For example, a Future Release story might get dropped if there’s no customer support or the business ROI is too weak. Future Release stories feed into the Release layer as openings occur. The third goal of backlog grooming is to validate the customer/business value of new features, prioritize them, and allocate to releases as space becomes available

The backlog and velocity

Let’s get back velocity and see how the product backlog and velocity are inseparable. At the Sprint layer, the amount of work, usually measured in story points, is based on team velocity. For four teams working from a single backlog and the cumulative velocity per sprint is 135 story points, the Sprint layer might have 405 story point worth of stories (3 sprints X 135). (I recognize that skill levels within teams matter and I talk about cross-skilled teams at the end but for the moment, assume the work is equally divisible by team strengths.)

For the Release layer, velocity is used to project work capacity into the near future, often 1 to 6 months or one or more releases. Below is an example of a multi-release story map from Steve Regalsky of Winnipeg Agilist. Story mapping is probably the best way to engage the development team(s) and get realistic commitments using their own velocity metric.

For future release layer, velocity plays only a small part in that you can estimate these features or new products by the number of sprints they might require to complete. This is done in portfolio planning where costing is done at a gross level. It’s a good idea to use T-Shirt sizing at this level to abstract the estimate and help prevent any premature expectations. The question development answers is how many sprints would this feature or new product take given your current velocity? A guide to T-Shirt sizing could be:

  • Small (S) => 1 – 3 sprints
  • Medium (M) => 4 – 8 sprints
  • Large (L) => 6 – 12 sprints
  • X-Large (XL) => 9 – 18 sprints
  • XX-Large (XXL) => Unknown

It would not be unusual for one Future Release story to be enough work for one or more releases.

Tips for getting and using team velocity

There are several activities that can improve velocity but there are also a few things a team or business can do to help make team velocity useful.

  • Keep the team intact and constant. This means no swapping people in and out of the team on a random basis.
  • Co-locate the team. The team sitting together will build stronger bonds over a shorter period of time.
  • Be patient and give the team time to grow. They’ll go through the stages of group development over a period of time but give them that time. Use team building exercises such as Journey Lines to help them grow closer.
  • Engage the team with the business early. Get the team thinking solving business problems and customer problems is their responsibility.
  • Do not use velocity as a stick. The team’s velocity is for the team to use and improve. Enable the team to improve and trust that they will improve.
  • Have the team create and agree to what success looks like. The team needs a common understanding of what Done means for sprint work.
  • Maintain strict adherence to how velocity is calculated. In its simplest form, velocity is a count of work completed, averaged over several sprints.
  • Improve ‘T-skills’ within and across teams. The goal is to progress work, not have everyone equally skilled. Reduce reliance on specialist roles.
  • Focus coaching and training activities to areas that can improve velocity. Maximize the value of agile ceremonies and interactions within the team, not just doing.
  • Be honest. Only count stories that achieve a ‘Done’ status towards velocity. A story that needs 30-minutes in the next sprint to be complete counts for 0 in the current sprint.

Cross-skilled agile teams

If the agile teams are limited in their skills and unable to work any story in the backlog, this complicates things a little. Velocity can fluctuate wildly when work needs divided up based on skill. This can hurt if you have a team but no work for their particular strength. In practice this usually means stories are not worked in a priority order. For example, the backlog might have stories targeted for IOS developers and Windows developers. However, within these categories, stories would be in a priority (customer value) order.

The only realistic solution is to upskill the agile teams so a team can progress most any story in the backlog. This is achieved by building ‘T-Skills’. ‘T-Skills’ means although there’s depth in a particular discipline, the person has some capacity across several other skills. Teams can begin analysing their ‘T-Skills’ with a skills matrix.


A skills matrix can help identify areas where weaknesses exist. For example in the matrix above, we see that several skills have only one contributor. These would be prime areas to begin any cross-skill training. Having Sid pair up with Alice on occasion to build his Backend skills might be a good idea. This would make two people who can do Backend work although not with the same rapidity but does allow work to progress when the key person is unavailable.


When will my agile team self-organize?

Great! Your business has decided to move from a Waterfall paradigm to Agile Scrum and now you’re waiting patiently for the benefits to kick in. You’re hoping your Scrum teams start self-organizing soon and are inventively solving customer problems faster with better efficiently. You’re also waiting for the team to become major contributors to the business decision process based on their intimate knowledge of customers and their pains. And you’re waiting … Still waiting …

You ask yourself what’s holding the team back. The Scrum Master has trained the development team on the agile manifesto including the principle:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

The Scrum Master has also trained the development team on self-organizing as described in the Scrum Guide:

  • defining the Scrum Team: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. … The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”
  • defining the Development Team role: “Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
  • defining the Scrum Master role: “The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality.”
  • defining the Sprint Planning Meeting: “The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint…By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”
  • defining the Daily Scrum: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.”

It’s clear the Scrum Guide expects the Scrum team, and more specifically, the development team, be a self-organizing body. It’s also clear that training people that they should be self-organizing isn’t always enough. The organization must want and the businesses actively support the team becoming self-organizing.

Setting Expectations

Getting a Scrum team to self-organizing is hard primarily due to the fuzzy nature of what ‘self-organizing’ actually means. If you were to ask 5 people to define what a ‘self-organizing’ software team is you’ll probably get 5 different answers. But even in that result some truths are seen, it’s not how I define self-organization, it’s how the team defines it.

In Nitin Mittal’s Scrum Alliance article, “Self-Organizing Teams: What and How“, he describes 5 essentials of self-organizing teams:

  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above.
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
  • Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.

I was once Scrum Master to a team during which I did training on the advantages of setting priorities, of sharing work, and of getting stuff done. The team was very good at their jobs and helped each other out whenever asked. However, I didn’t realize helping out had a limit until one day at the daily standup when the person working the most important story, the highest priority story, was out. I asked who could pick up the work to move it forward? No one raised their hand. One of the quietest people then said it was massively inefficient to have someone else pick up the work. For me personally this was a sad, sad day. After talking priorities, talking of sharing work, talking of getting stuff done, and talking how the team best works together, the team couldn’t let go of their own personal task responsibilities. The team couldn’t find it in themselves to embrace a team responsibility of getting the most important work done first. A self-organizing team would have kicked into a self-managing mode and re-allocated work so the highest valued work could continue. At the end of the standup, team members felt a stronger bond to their own work in areas they were most comfortable with than to the whole. It wasn’t competency but rather motivation that was holding the team back.

What makes it so hard to motivate a team to feel responsible for the whole? When a business pushes individual roles & responsibilities over team commitments or when survival and blame permeates an environment, it’s very unlikely that the team will move beyond the ‘forming’ stage (team members sticking to what they know best individually and doing what they feel most comfortable with).

In some business environments, the dip in productivity while transitioning from ‘Forming’ to ‘Storming’ is unacceptable. This would be especially true in a strong hierarchical or Command & Control environment where those in the hierarchy are held responsible (accountable) for team performance.  If the business is clinging too tightly to a hierarchical and Command & Control environment, the likelihood of birthing self-organizing teams is diminished. At one company I was at, one of the most senior software engineers was a team lead. The team was always seeking his approval for any decisions and if the manager thought otherwise, the team changed their ideas to conform. This wasn’t the worse thing to happen but it was heavily reliant on the team lead always being right. A consequence of this was lower scores on the company’s engagement evaluations especially around empowerment and feelings of trust.

It’s worth the attempt

Adopting Agile and Scrum will not automatically cause people or businesses to change. For Agile and Scrum to make a positive impact, people will need to see that they need to change their own behavior. It’s possible to see that in an environment where individual knowledge or individual skills are the most sought after commodity, Agile may not be the right tool. In a business where rigid hierarchies and Command & Control are dominate, it may be a long journey to establishing self-organizing teams but certainly worth the effort.

David Ticoll in his Harvard Business Review article, “Get Self-Organized”, states that, “It would be difficult and risky—even foolhardy—to try to wholly transform a hierarchical business model into a self-organizing one. But the potential of self-organizing systems to enhance competitiveness is becoming clear to managers of some conventionally structured businesses.”

David Tricoll further states, “Today, the ability to stream complex, real-time information to the front line gives hierarchical companies greater power than ever to exploit self-organization.”

One approach might be getting the team to participate in business events such as creating business plans, working with customers and users, and respecting them as contributors to business success. Teams with greater insights to business and customer problems are more likely to be engaged with solving these. To be quick and competitive, businesses must relinquish control to the teams in the front lines and the teams must be willing to accept the responsibility. When the business leaders and development teams shared these insights, I’ve seen the development teams rise beyond their own specialties to rally around both the customer and the business.

For a team to become self-organizing, it will take more than a business to want and support it, it requires the team itself to see advantages in self-organization. If you’ve ever seen how an assembly line worked in days gone by, you’ll see an environment where self-organization would have been detrimental. Your job was to put nut ‘A’ onto bolt ‘B’ period. Repeat this for 8 hours a day, 5 days a week and you got paid pretty well for what to some people would be the most boring job on earth. The business wasn’t holding out hope that the workers would self-organize and the workers had no motivation to do so. In the factories, piecework was common. Workers were told what to do, how to do it, and when to do it. Software development is not piecework, if it were, robots would be doing it today. It is knowledge work where thinking both inside and outside the box are assets to the business.

In the situation above when a team member is absent, the moment the remaining team members decided that doing and completing individual tasks is more important, all advantages of self-organization were lost. Instead of adding value for the customer and business, the team had elected to follow a plan. The decision essentially comes down to: I have my own work to do and don’t have time to do yours.

To some, this kind of dedication is how you advance in the company. However, if the company were to emphasize customer and business value of work being done, it would cause a fundamental shift in team thinking, from doing tasks to getting the highest value work done quickly. When the business puts emphasis on value, the team is more likely to devote their combined efforts to achieving value. It would come to pass that even when one of their numbers is absent, progress won’t stop, although it may slow down. If the team is accepted as a fully participating business team member, not just a partner, the team will genuinely feel the success of the business is also their own success and act accordingly.

To me, one of the principle tenets of Agile is the team. The great power of Agile comes from a group of intelligent people working as one. Collectively they are more knowledgeable than any one individual although the shared experience may be less. To ignite the team requires the business to openly give the team responsibility and accountability for the outcomes of each iteration. For the business to move forward and empowering the team, they would need to establish safe boundaries from which the team can safely operate in.

When business leaders, product owners, and scrum masters attend the daily standup, what’s more important than hearing team members say,

I completed task <x> yesterday”,

is hearing them say,

we added <some> value to the product yesterday”.

The role of managers and customers on the self-organizing team

In an InfoQ interview, Rashina Hoda cites two environmental factors needed to be in place to enable self-organization to emerge. These are:

  1. Senior management at the teams’ organization must be able to provide freedom to the teams so that they can self-organize themselves.
  2. Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.

“Self-organizing Agile teams … require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative.”

– from “Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?” by Rashina Hoda, James Noble, and Stuart Marshall


For the business leaders, giving development teams insights to both business and customers plus giving development teams space to operate, will motivate teams to accomplish amazing things. When the business states these are our goals and asks the team to solve it in the best manner possible, you’re likely to see a team self-organize to meet the goals. No one goes to work hoping they fail.

When the business has a strong hierarchical and Command & Control environment, moving a team toward self-organizing is made more difficult but not impossible. Building a bridge of trust and respect is essential. By establishing a strong partnership between the business and development team, followed by full membership, the team can exercise their collective knowledge and capabilities to contribute to business successes.

In the end, it’s a mutual effort on the part of both management and the development team to become self-organized. It will probably be a bumpy ride along the way but with a clear goal as a guide, both should arrive at the destination together.




User Stories: The Product Manager & The Development Team

If you’re being Agile, …

Sorry, it’s not about Agile but about customers and customer value. Let me start again.

If you’re using User Stories as the vehicle for product creation and improvements, the product manager and development team can both be best served if they share a strong understanding of the business rational and customer problems to be solved. The user stories act as the bridge between business goals and the value the product brings to the customer for all stakeholders on the business/product team. In Scrum, the product manager is often called a product owner. Depending on your business, the product manager and product owner could two people but for this article I assume they’re the same person.

In the 2016 Scrum Guide, the role of the Product Owner is defined as the sole person responsible for managing the Product Backlogand “is responsible for maximizing the value of the product and the work of the Development Team.”

This is usually where some people get the false notion the product owner does all the work to create and maintain the product backlog including, writing all user stories. At one company, I was confronted with the development team’s manager telling me, “are you trying to make us all product owners” when it was suggested the development team could help breakdown and write user stories. This is a common misconception of what the product backlog and the role of the Scrum product owner are all about. If one were to read a bit further, the Scrum Guide clearly doesn’t want this to be a one person band; “The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

The idea that only one person is doing the work is different from one person being responsible for the work. For example, as a parent, you feel responsible for the education of your child but although you help with homework, the larger proportion of the educational tasks are left in the hands of others. As a parent, you are responsible yet trust the education of your child to trained and experienced experts. So too is the work of populating, refining, and prioritizing the product backlog.

“Business people”

“Business people and developers must work together daily throughout the project.” – Principles behind the Agile Manifesto

The business has entrusted their reputation in the Product Manager to manage a product. However, the Product Manger is not usually the sole decision maker when it comes to what to do with the product and when. Below is an insight passed on by Jeff Patton during his talk, “Top Ten Myths of Myths & Misconceptions of Product Ownership“.

Myth 1. You’re the decision maker for what product to build and when.
Reality: You generally lack authority to make decisions; you’re only the decision maker if everyone agrees with your decision.

The best Product Owners [Managers] make decisions based on a synthesis of suggestions and ideas from SME’s, Customers and Users, Business Stakeholders (CEO, Boards, Marketing, Finance, Sales), and the development team.

You’re the glue that holds SME’s, Customers and Users, Business Stakeholders, and development team together
You’re the lubricant that keeps things moving
Basically you stick and slide at the same time

(from my notes of the talk)

The product manager is not alone and gets input from business leaders, product leaders, and management. What sometimes gets forgotten is the development team. The product manager, business leaders, product leaders, and management all have a vested interest in getting the development team on-board with business strategies and goals. The development team, along with of the product manager, are the people who know the product best. The development team is not simply a partner in the business but a full-fledged member of the business team and should be recognized as such. And because the development team is made up of multiple disciplines, the advantages of this relationship is getting a diverse and unique perspective that developers, testers, BA’s and UXD people have of the product and of the customer problems to be solved.

Business decision and policy makers can choose to use or ignore any information obtained from any team member. It’s the difference between Authoritarian Decision-Making and Democratic Decision-Making; the Authoritarian makes the decision and doesn’t ask or care for the opinion of others while the Democratic Decision-Maker gets thoughts and ideas from others but still makes the final decision based on a diversity of ideas and opinions. The product manager can make the most learned decisions when provided with wide view-point of ideas and opinions.

Some points a product manager can experiment with while bringing development team members into the business decision process.

  • Builds business cases with product team, development team, marketing, sales, support, and management to achieve business goals through new product development or marketing.
  • Collaborates with one or more development team member to complete the business plan/Lean Canvas.
  • Collaborates with one or more development team member to gather technical feedback and suggestions for feature road map items and UX concept designs.
  • Provide shared vision and understanding of business attributes of road map items to one or more development team member

“and developers must work together daily”

So while the Product Owner [Manager] is held responsible for the product backlog, he or she must work collaboratively with many others to get the best product to the customers and users. A product manager works with business leaders and other business experts but also utilizes the “developers” to help. Now this is a two way street. Our manager above who asked if developers were to become product owners is not being an obstructionist but is likely supporting a business stance that roles are roles and one does not step across the abyss. Although a very traditional idea, it’s not an idea that will make collaboration and cooperation flourish in the organization. Some additional product manager role insights from Jeff Patton.

Myth 4. You work alone
Reality: Usability is generally determined through Users, UX people, and BA’s; Technically Feasible is generally determined through architects and Engineers; Business Value is generally what the Product Owner brings through conversations with customers and stakeholders.

All these people make up what is called the product team.

Most successful organization define a Product Team. Some dysfunctions of the Product Owner:
  – Don’t socialize decisions;
  – Don’t spend enough time with the team;
  – Don’t spend enough time with the customers


Myth 5. You create the backlog alone
Reality: Product Owner works with the product and their most important skill is leadership. Good leaders collaborate & motivates everyone; builds whole team ownership.

Product Owners give clear guidance and engage others to build & prioritize the backlog.
Product Owner not a good name; Product Manager not a good name. The role is not singular in scope or conduct.

(from my notes of the talk)

In organizations I’ve been in, the best behavior for getting the best product to customers was a result of product management and development teams working closely together. This would go beyond collaboration and reach the point where product and development shared an equal desire to deliver value to the customers in order to achieve a business goal. Of course both the product manager and development team bring their unique skill sets into play to reach a symbiosis of sorts. This kind of relationship doesn’t happen overnight and probably won’t be a painless journey, but success can happen. In one role, I was entirely unsuccessful in uniting product and development in this way but even in my failure, the two worked together in harmony, they just didn’t feel the same level of responsibility for defining the value through user stories. Of course, writing user stories is not the point, satisfying the customer is but over the years, I’ve noted development teams usually start from a technical place and need nurture to move beyond this mindset. There’s always room for improvement.

Another challenge is having the product manager to ask for or seek help from the development team, with creating the defining the business case for the product and creating/maintaining the product backlog. Consider for a moment a product manager who can’t let go of the idea that they and they alone create and build a product backlog. This most often is about trust and can manifested itself in the depth of detail of user stories written by the product manager, something that almost certainly guarantees resentment from the development team.  The breakdown in my view begins with the product manager and the development team not equally engaging with the customers and users from the start. The product managers did most of this alone without development. One way to ease the burden of writing stories is to begin introducing development team members into customer interviews, user testing sessions, and user observation sessions.

Another point of concern the product manager might have is a fear the development person might say the wrong thing in front of a customer. This is common fear and one that is not often substantiated with facts. In my view but can easily be overcome by getting the product manager and development team members to agree on behavior. Stress that the developer be allowed in the room during the interview but only for listening and note taking, at least in the beginning. This by far is the easiest way forward as the product manager and development team can build trust. It won’t be long before the product manager asks the development team member if they have any questions for the customer. Another big advantage to this is the development team member’s perspective on what the customer says. In the debrief after an interview, the development team member and product manager will probably find they interpret the same thing differently, which brings a richness to the interview missing if the product manager did it alone.

Getting the development team engaged with business cases and creating user stories isn’t often too a big issue but they generally don’t put up too much of a fight if the product manager insisted on doing it themselves. What important is that work isn’t done in total isolation with results passed from product manager to development team. This is type of hand-off is a key intersection of miscommunication. Results should instead be the result of collaboration and communication. This level of collaboration and communication needs to happen throughout the project, beginning to end, to reach the highest potential.

Some points the development team can experiment with to broaden their business and customer insights.

  • Provide technical feedback on feature road map items and UX concept designs.
  • Support (help create) and provide feedback on Business Plan/Lean Canvas.
  • Create and support User Stories to achieve business goals through new products or product improvements.
  • Provide estimates for the software components of road map items.Provide software estimates for user stories.
  • One or more development team member fully understands the business attributes of a road map item.
  • One or more development team member fully understands the customer pains and how solving these contributes to the business goals.
  • Development team actively participates in product backlog grooming sessions.