Sprint Planning start well, end better. 

Photo Credit: Pixabay- WOKANDAPIX

“Plans are worthless, but planning is everything.”

Dwight D. Eisenhower

Has any of this happened to your Scrum Team? 

  • The team regularly takes on more work than they can complete in a Sprint.
  • Work is removed from the Sprint because it could not be completed.
  • The quality of the final work is low, with many issues found after the Sprint.
  • Stories grow in size during the Sprint as more work is discovered.
  • Arguments erupt on the right approach to getting work done.
  • Sprints looked successful, only to have the stakeholders say it doesn’t meet business needs.

These challenges and more can be traced back to poor Sprint Planning. 

The Basics of Sprint Planning

Sprint Planning marks the start of each Sprint. It sets the overall tone for Sprint. Good Sprint Planning leads to a good Sprint. A Sprint that doesn’t generate value is creating waste. 

Let’s start with a quick primer on the five Ws of Sprint Planning:

What? (Definition)A planning event to create the Sprint Backlog, which answers the questions: “Why are we doing the Sprint?”, “What work will be done?” and “How will the work be done?”. 
Why? (Purpose)To create alignment on the purpose and work needed to deliver on the Sprint Goal. 
When?Sprint Planning is the first event inside the container event of the Sprint. The Sprint starts when Sprint Planning begins. 
Who?The Product OwnerThe DevelopersThe Scrum MasterStakeholders and SMEs as needed
How long?Two hours per week of Sprint

Now we’ll unpack some of these to understand better and learn how not doing them could impact your Sprint…

Unpacking Sprint Planning

Why do we do Sprint Planning? 

We do Sprint Planning to create alignment and purpose around the Why, What, and How of Sprint Planning. 

  • Why is it valuable? (Creating the Sprint Goal.)
  • What can be done in the Sprint? (Populating the Sprint Backlog.)
  • How will the chosen work get done? (Breaking down the work)

If we don’t answer all three questions, we don’t have true transparency of the work and how it connects to the whole. 

The most common places I see Sprint Planning, and by extension the Sprint, fail is with the Why and the How parts of Sprint Planning. 

There is no Why: No Sprint Goal.

The Scrum Guide defines the Sprint Goal as “the single objective for the Sprint.” To this definition, I add it is “a concrete stepping stone towards the Product Goal.” 

If your Sprint Goal does not connect to your Product Goal, then you are not “maximizing the value of the product resulting from the work of the Scrum Team.” Without value, you can’t be profitable. Without profitability, you can’t be a sustainable business. 

Defining a Sprint Goal at the beginning of Sprint Planning is critical. Defining the goal upfront allows all the work pulled into the Sprint to support the Sprint Goal, enabling the output and outcome of the Sprint to contribute towards the Product Goal. 

There is no How: The work is not understood.

One of the reasons for Sprint Planning is to create alignment between the Product Owner and Developers. Alignment is not just between the Product Owner and the Developers. It is also between the Developers. Does the database expert know how the business logic person will implement their work? Is everyone clear on how the end product will be tested? How will we demonstrate this? If the team is not asking these questions in Sprint Planning, you are headed for rocky waters.

Who attends?

Many Agile teams treat the Events like secret Star Chamber meetings requiring a password to enter. Scrum works on the fundamental pillar of Transparency. Without transparency, everything else in Scrum will suffer and eventually fail. 

With Sprint Planning, transparency is essential as it is the last chance to refine and understand the team’s work in the Sprint. Inviting the business stakeholder to provide greater context, or the Architect, to work through some design questions can be the difference between a Sprint Review where everyone says, “That was awesome!” and one where you hear, “That’s not what I wanted” or “You realize that’s not security compliant and you need to redo it?”

How long?

The Scrum Guide says: 

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Eight hours? That’s an entire day! Are you serious?

Let’s do a little math here. A one-month Sprint is, on average, 20 days or 160 hours. Eight hours is just five percent of the total time of the Sprint. Five percent!

Now let’s look at a typical waterfall project. Twenty years ago, the projects I managed were typically 12 months long. The first three months of that project were back and forth between product management and development on precisely what would be built with no code being written (for this release) for at least two months. Plus, the product managers had previously written requirements documents for at least two months.

Twelve months, with two months spent in “planning.” That’s 16 percent of the release spent on planning. And let’s be honest, that’s probably on the low side by a generous margin.

So, yes, two hours per week of Sprint is not only reasonable, it’s responsible. We’ve already looked at the two common failure patterns above. Lack of sufficient time is not only our third failure pattern, it also causes the first two. 

And let’s remember; the Scrum Guide says “a maximum of.” If the team finishes before the timebox, no one will complain and demand you all stay until the timebox ends. Schedule the time so you have it. Nothing is worse than having a two-hour meeting and finding out you needed two hours and fifteen minutes. 

In the next section, I’ll show you my agenda for a two-week Sprint.  

Agenda for an Effective Sprint Planning Event

The following is a recommended agenda flow for a two-week Sprint and has a four-hour schedule. 

Set the StageWelcome attendees and set expectations~5 min
WhyThe Product Owner describes a possible Sprint Goal and then discusses it with the Scrum Team~10-20 min
WhatFinal Refinement and Estimation occur on Product Backlog Items (aka stories) that the Product Owner desires for the Sprint~15-45 Min
WhatThe team reviews their availability and past performance to determine their potential capacity for the Sprint~10-15 Min
WhatPopulate the Sprint Backlog with the Product Backlog Items that will meet the Sprint Goal~15-30 Min
HowThe Developers plan how they will complete the items in the Sprint Backlog~2 hrs
CloseTake a final confidence vote, thank the team, and end~5 min

1. Set the Stage: In their book Agile Retrospectives, Esther Derby and Diana Larsen say, “Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective.” The above is good advice for all the Scrum Events, and I start Sprint Planning by thanking everyone for their time and reminding them of the purpose of Sprint Planning.   

2. Establish a Sprint Goal: We’ve already discussed how failure to create a Sprint Goal or even creating a Sprint Goal after deciding what to do is one of the top reasons Sprints fail. If Sprint Planning sets the tone for the Sprint, the Sprint Goal sets the tone for the planning. 

The Product Owner should come prepared with a recommended Sprint Goal. This Sprint Goal can result from the Sprint Review the day before or based on other strategic work. To be effective, the Sprint Goal connects directly to the Product Goal. The team then discusses, refines, or changes the Sprint Goal. 

3. Final Refinement and Estimation: You should already be doing regular Backlog Refinement to keep your Product Backlog topped off with regular work. That said, Sprint Planning is the “last responsible moment” to do refinement. Check out the Scrum Alliance article linked above for more on Refinement. 

Generally, I see three kinds of refinement happening during Sprint Planning. From most common to least, they are: 

  • Reestimation of work
  • Updated Acceptance Criteria
  • New, usually urgent, work

Reestimation can happen at any point up to when the team starts working on the item. Say that the last refinement session was the Thursday before. Since then, Sunil has been rummaging around the data layer and has discovered several new connections to other processes. Sunil returns to the team and says, “I think we underestimated the complexity.” The estimate for the item could change right there in Sprint Planning. 

Acceptance criteria are how the Product Owner can shape the value of the work. The PO may want the new login page to be 25% faster than the last one. Martha has been looking left, right, and sideways at the code, and she doesn’t think the team can squeeze more than 15% out of the current system. The PO then decides if getting the new login page now is more important than getting it to load faster. The PO wisely decides now is better and agrees to change the AC to a 10% improvement. 

And finally, remember that the Product Backlog is dynamic and emergent. New items can shoot to the top of the backlog overnight. The Product Owner may bring a brand new item to the team and ask them, “Can we refine this and include it in this Sprint?” While this should be uncommon, it should also be possible.

4. Determine Sprint Capacity: How much work can the team do on average? Will anything impact the team’s ability to work this Sprint? A great example is what to do when a major holiday falls in the Sprint. Instead of the team shortening the Sprint, they consider how this will impact them. If the entire office shuts down for a week, then the team’s capacity is 50% of what their velocity says they can do.

5. Populate the Sprint Backlog: Once you have a capacity guide for the Sprint, the team can fill the Sprint Backlog with work that supports the Sprint Goal. There are many ways to do this. Just remember that the Developers pull work into the Sprint. The Product Owner decides if the work to do has value and contributes to the Sprint Goal; the Developers decide how much work they can do in a given Sprint. 

6. The Developers plan how they will complete the items in the Sprint Backlog: This is the most frequently forgotten — and therefore problematic — part of Sprint Planning.

 Here’s how I explain this to  students:

 “When Sprint Planning starts, you are coding! Not all coding is hands-on keyboard typing. There is whiteboarding, design conversations, coordination, and more.”

If the developers need to look at the code to determine how they will build something, then look at the code. Scrum Masters, this is one of the places you are most needed. Ask questions, and seek clarity. Does the team understand what they will do, or are they planning to “just figure it out as we go?” That’s not Agile; that’s just lazy. 

The How phase is the most time-consuming part of Sprint Planning. Done well, it prevents rework and conflicts (people, process, and product). It allows for a greater chance the team will deliver a usable increment of value (AKA done work the customer cares about) at the end of the Sprint. 

Here are some things Developers should be doing in Sprint Planning:

  • Break work down “into smaller, more precise items.”
    • AKA create individual tasks that represent the technical work needed to complete the Product Backlog Item. (UI work, DB work, code review, create automation tests, etc.)
  • Whiteboarding the design
  • Sketch the user interface
  • Review existing code
  • Anything required to plan how to complete the work

Breaking work into tasks is vitally important and should never be pushed out with a “we’ll figure it out later.” Tasking allows for: 

  • Remembering the work: Five days from now, will you remember what you discussed in the Sprint Planning meeting? And if you didn’t even talk about it at Sprint Planning, do you remember when you did talk about it? 
  • Alignment: How will the UI work fit into the Business Logic work?
  • Track Progress: If you break work into tasks of no more than four hours, your burn-down charts will reflect progress toward the Sprint Goal more accurately. 
  • Create stronger teams: When the team breaks work into bite-size pieces, it often allows someone with less skill to pick it up and complete it. This benefits the team in creating more cross-functional members and benefits the individual who gets to improve their mastery. 

The Product Owner during the How

What does the Product Owner do during the How part of Sprint Planning? Unfortunately, the typical pattern is “See you all later; let me know how it goes.” 

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” 

The Scrum Guide.

The work is still all about value. If the Product Owner isn’t present, important questions might go unanswered, acceptance criteria can’t be tweaked, and problems not detected until too late.  

The PO should be present and available. Their presence will ensure a continued alignment to value. 

7. Close: Closing can be an under-appreciated part of good Sprint Planning. In Agile Retrospectives, the authors say, “End the retrospective decisively: don’t let people (and their energy) dribble away.” 

Remember the maximum timebox. If the team is still going strong at three hours and fifty minutes, the Scrum Master can ask the team what’s needed to wrap up. Maybe they didn’t get all the work planned out. What will they do about that? Do they need to de-commit some work before the Sprint starts? 

One of the things to do here is to collect a confidence vote. Now that the Developers have planned the work, how confident are they that they can complete it all in the Sprint?

Using the Fist to Five consensus framework is an excellent way to check on confidence.

Working with multiple teams

What happens when a Product Owner is supporting multiple teams? This is not immediately a bad thing. The Scrum Guide even has a suggestion:

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” 

The critical point here is that to be effective, the Product Owner must only have one Product Goal at a time. The next question will be, “How many teams can one Product Owner support?”. 

My answer is 2

There are other answers and arguments, and we’re stepping into scaling conversations now. My experience is that a Product Owner becomes exponentially less effective beyond two teams. Once you move to four teams, you need to insert a scaling practice to have someone focused on the longer term while Product Owners continue to be sleeves rolled up and engaged with no more than two teams. 

In practice, the way I’ve coached Product Owners supporting two teams is as follows: 

  • Shared Backlog Refinement
    • Not everyone has to be in refinement sessions. Ensure you have representation from both teams and that all skills needed to complete are represented.  
  • Shared Why and What Sprint Planning
    • This allows alignment, horse trading of work, managing dependency, and more. 
  • Individual How
    • Do these at the same time with the PO floating between both teams. 
  • Individual Daily Scrums
    • Stagger them so the PO can go to both
    • A representative from each team should go to the other Daily Scrum
  • Individual Retrospectives
    • The PO rotates attendance every Sprint
    • Every quarter or so, do a combined retro on overall ways of working. 

A good Sprint Planning Event creates Value and Quality

The concept of “Starting on the right foot” is not just a trite saying. If you want to improve the quality of your work, improve the quality of your Sprint Planning.

Metrics: Third Rail of Agile Adoption

“Am I good or what?” The question was, of course, rhetorical, I was alone in my office. I

Photo Courtesy of: https://www.flickr.com/photos/bike/

Photo Courtesy of: https://www.flickr.com/photos/bike/

couldn’t help it though, I was pleased as punch and nothing was going to ruin my great mood.

“Or what?…”

Not even an 800-pound invisible gorilla.

“Go away, Hogarth, you can’t ruin my mood today. I’m on top of the world.”

Ignoring me, Hogarth ambled into my office. Spotting my new fichus, he plopped himself down and tore a branch from the tree. Around a mouthful of leaves, he asked: “So, agile adoption going well?”

His question instantly dispelled my annoyance at his assault on my plant. “Yes, yes it is.” I turned the monitor around so he could see. “Just look at these velocity trends! Every team is hitting or exceeding their velocity targets and we’re only three sprints in. It’s absolutely fantastic!”

Hogarth leaned in and intently studied the flat screen display. “Impressive. That’s got to be one of the fastest velocity growths I’ve ever seen. What did you do differently this time?”

“Hey, I’m just good. Awesome training, great coaching. Oh, and I bet the incentive program really helped out.”

Hogarth cocked his head to the side, “Incentive program?”

I leaned back smugly, “Oh, yeah. If the teams hit the velocity goals then they get a cash bonus and we’re going to hold a huge party at Humdingers Resort.”

Hogarth nodded, making some appreciative sounding grunts. I’d finally gotten to him. He was speechless.

After a long gaze at the monitor, he turned to me and gave one of his brilliant white smiles. “Sounds like a real Goodhart moment.”

It was my turn to cock my head in confusion. “A Goodhart moment?”

My gorilla nodded at me, “Uh huh. A well known British economist has an economic concept named after him. The layman’s version of Goodhart’s Law states, ‘When a measure becomes a target, it ceases to be a good measure.'”

I looked at Hogarth. I looked at the velocity reports. I looked at Hogarth. “You mean…”

He nodded, “Yup, those velocity metrics are about as useful as wheels on a speed boat. They look good spinning, but they are not really doing anything.”


Metrics- Can’t live with them, can’t live without them.

“Metrics are not bad, managers using metrics improperly is bad.” was a quote I sent out on Twitter (@JBC_GC) during Agile Open Northwest 2017. The session was “Why do metrics get a bad rap?” and it was a lively conversation with some surprising outcomes.

I’ve had a lot of success with the healthy use of team metrics. I’ve used the afore mentioned Goodhart’s Law as a conversation starter on the good use of metrics many times. And despite my success with team metrics I had never really articulated, to myself or others, what the disconnect between team metrics and management’s desire to set goals on those team metrics was. Turns out it is rather a simple thing.

Managers don’t actually care about metrics. They care about success.

Managers want to know if the product will ship on time or with the promised features or with the promised value, or all of the above. They end up using team metrics because it’s all they have. And in the classic square peg in a round hole scenario, they were hitting the square peg with the hammer to make it fit.

And how’s that worked out for us? Even in the well run agile project, the ability to tie team estimates and metrics to actual shipping dates is a highly mixed bag. We are horrible at estimating, to the point that the #NoEstimate movement is gaining traction through being right. This, however, is not a rant about how bad we are at estimating, using no estimates or even bad metrics. It is instead a look at what we can do about this disconnect between Team Metrics and Management need.

Step 1: Recognize managers need better forecasts, not better metrics.

Step 2: Stop using Team Metrics for forecasting.

Step 3: Give managers the tools to let them forecast.


Step 1: Recognize managers need better forecasts, not better metrics.

The best use of metrics is “as a lagging indicator of if we might want to talk to the team and see if they need help.” This is the coaching advice I give to management and teams, usually shortly after quoting Goodhart’s law. Metrics will not tell you when a team will get done without the risk that the metric will run afoul of the wisdom of Mr. Goodhart.

Just as you want to know if you should pack an umbrella tomorrow (or wear sunglasses, or get your snow blower ready), management wants to know if the project will be successful. A totally and perfectly valid request. Only you don’t use team metrics for this. Even when metrics are used as the source data, they are still being used to forecast. We look at velocity trends to estimate when a team will be done. That’s forecasting, not metrics.

Step 2: Stop using Team Metrics for forecasting:

Performance based on incentives doesn’t work. When we try and use metrics to drive performance we get Goodhart’s Law. The example I like to give comes from the book Freakanomics.

To summarize: India was having a problem with cobras. To address the problem the government came up with a great idea. They would give a bounty on every cobra head turned into the government. The program was a rousing success, just not in the way the government intended. People started raising cobras just so they could collect the bounty. In short order, India’s cobra problem was even larger than before the bounty was put in place.

If you tell a team they must make a March 15th release date. They will very likely hit that date or come really darn close. And then the company ends up dealing with bugs for the next five years. “When a measure becomes a target, the measure is no longer valid.” If you’re struggling to get your message heard, you might try showing them Dan Pink’s RSA Animate video to reinforce that knowledge skill teams don’t work best from incentives, they work best from Autonomy, Mastery, and Purpose.

Of course, not everyone is going to listen, even when they pay us for our advice.  Which is why I advocate limiting the metrics used and make them interlocking. Game one metric and the others will react in the negative. My four metrics are based on Jeff Sutherland’s three recommended metrics and a fourth I’ve had a lot of success with. They are:

  1. Cycle Time
  2. Escaped Defects
  3. Happiness Metrics
  4. Planned to Done Ratio

If you game cycle time so it’s really short, quality will almost certainly suffer. Let quality slip and you see an increase in cycle time and escaped defects. If planned to done is too high, then quality is probably suffering. And if metric 1, 2 and 4 are all really great and happiness is suffering then you have a strong indicator that you’re burning out your team.

Step 3: Give managers the tools to let them forecast.

This one is really easy. Stop reading my blog and go to FocusedObjectives.com. Troy Magennis has crossed the streams of mathematics, classic project management forecasting and agile to come up with a tool that allows managers to forecast when a team(s) or feature(s) will either be done or if it will hit the desired schedule.


I’ve seen this tool in action and heard stories from several users of Troy’s Forecasting approach. With this tool, the managers no longer need detailed metrics from the team. They can build forecasts based on as little as a half dozen data points, which can even be made up for initial forecasts. With just cycle time data points, you can run massive Monte Carlo simulations to get 80-90% accuracy on your forecasts (note, anyone who claims 100% accuracy is also gaming the system, or in denial).


So keep team metrics focused on improving the team. Give management their own tool for forecasting schedules and/or capacity. Then watch as the results of this is the teams getting, even more, work done, with greater predictability, and greater happiness.

One Size fits all Gorilla? No more Telecommuting?

“Look, Eric, that’s just not the way we work here.” I was trying to go for my most fatherly voice with this. It was a touchy subject. “You’re an incredible engineer, you’re awesome with the rest of the team. And the mentoring you do is priceless.” I clasped my hands together and tapped the desk with them, “but at this company we just can’t have people marching to their own drummer. You need to adjust your work schedule. We have policies and procedures that apply to everyone and that means you need to be here in the office everyday, or you can’t work on the team…”


An hour later I leaned back in my chair with an exhausted sigh. Wow, I was wiped out. That kind of meeting never goes well. But it had to be done, policies are policies and if it’s good for the boss, it’s good for everyone. What’s that saying about “what’s good for the goose is good for the gander”?


My office door opened just then. I looked up, half expecting to see a tearful Eric back to plead his case. Instead the light beyond the door was all but blotted out by the broad shoulders of my personal gorilla, Hogarth.

“What do you want, Hogarth?” I wasn’t going to let him get to me this time. I’d been enforcing company policy and I’d done it nicely and professionally. He couldn’t get to me this time.


Hogarth ambled in, swinging forward on one arm as the other reached out towards me with something.  “I just came to make a delivery,” Hogarth said. “Here’s your T-Shirt for the company picnic.”  He handed me over a folded black shirt that looked  minuscule in his hands. When I took it from his gorilla-sized hands I found the shirt didn’t look all that much larger in my hands.


Holding it to me I glared at my gorilla, “Hogarth, this shirt wouldn’t fit a pygmy. I don’t think my shoulders will even fit through the arm holes.”

Hogarth gave a shrug, “What can I say, Marketing ordered a ‘one size fits most’ people. Guess you’ll just have to adjust yourself to fit…”


Ouch, hoisted on my own words. I really have to stop doing that.





Yahoo CEO tells remote workers to report to the office (Huffington Post)

The recent news, that Yahoo’s CEO has ended telecommuting has started up a firestorm of fresh debate and exposed the coals of long smoldering arguments on the subject.  According to the articles, all telecommuting is ending. From the customer service rep, who works full time from home, to the engineer who works from home one day a week so he can save on that hundred mile commute.


The reasons CEO Mayer gives should sound familiar to agilists everywhere:

“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. “


Sounds almost like Mrs. Mayer was reading out of the Agile Manifesto when she wrote her memo.

“The most efficient and effective method of  conveying information to and within a development  team is face-to-face conversation.”


Business people and developers must work together daily throughout the project.”


I’ve worked on both remote and local teams and I can’t argue with Mrs. Mayer’s general logic one bit. There is nothing that beats face to face conversation. All the best that technology can offer still only scratches the surface of replicating that face to face experience.


And yet I find myself agreeing with those that are up in arms about this policy.


1: Are we in prison? First and foremost it is a mandatory policy, no or very few exceptions will be given. This reminds me of the agile principle that sits right between the two Mrs. Mayer seems to be playing from.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”


Give them the tools and the trust to get the job done. Yahoo’s move isn’t giving people the tools and trust. Instead its making a mandate that covers all teams, all projects, all people, all locations. Even universities and public K-12 education have realized that some students will thrive better with virtual learning, than with face to face. You don’t motivate teams by locking them in a room and feeding them pizza. At the end of the day, the room is still locked.


2: Everyone must work in the office, which office? In the Yahoo memo Mayer says ” From Sunnyvale to Santa Monica, Bangalore to Beijing…” Well let’s see here. Say I work in Customer Support and I live in Santa Monica. The head of Customer Support and the largest team are in Bangalore, in fact there are no other CS folks in Santa Monica. Does this mean I have to move to Bangalore? My job is very internally focused on Customer Support. Sure, there are advantages to being able to go to lunch with HR. At the end of the day though, I still am not seeing my team face to face.


We live in a global society now. With projects often having dozens if not hundreds of people involved, it is nearly impossible for everyone on the project to be co-located. Someone is always going to be working remote. What’s the difference between the remote engineer sitting in a sales office in Des Moines and a remote engineer sitting in his home office in Windsor Heights (a suburb of Des Moines)? In High Tech, it has become increasingly common for test organizations to be located in India or China. Is Yahoo going to relocate all these people to Sunnyvale so that they can be next to the engineers making the product they test?


3: Get the right people on the bus: I reviewed Jim Collins book, Good to Great, back in November of 2011. Mr. Collins makes a very compelling argument for getting the right people on your team, instead of getting the right skills on your team. The same concepts hold true in military special forces, where a team trains together long term and learns the skills they need for a new mission together, instead of bringing a new person in.


Say you find the most brilliant engineer for your project. Not only does she have all the skills you need, she fits great with your company culture and the team. You know she’d be a great asset. Only your offices are in San Francisco and New York. The engineer is in North Carolina and can’t move because she takes care of her ailing mother. Do you pass up on the engineer who gets a perfect 10 and instead hire the local engineer who gets a 6, just because he’s local?



Working co-located is great! – Don’t get me wrong. When I’ve had the luck of working with a team, all in one place, the effects are awesome. The issue here is like an army handing out size ten boots for everyone, because that’s the most common boot size needed. What happens to the guy who wears size 13, or the woman in the size 4s?


You do what is right for the team. You remember that your teams are not the entire company. You remember that one size never fits all.


Oh! – In small defense to Mrs. Mayer. For all of you remote workers who don’t want to use a webcam in your meetings?


Get over it. Working remote doesn’t mean you get to come to work in your pajamas. It means you have to work 200% harder to connect with your other co-workers. Video chat is here, it is real, it is now. Use it, or get your butt into the office.


One size won’t fit the Gorilla and it won’t fit your employees either. 


Hogarth and the Gorilla Talker