During project planning, communication is often overlooked. Most project plans only consider the actual development – but what about discussing and explaining the tasks at hand? You know how they say, “The truth is born in an argument”? Talking about what the team is supposed to do can not only bring the truth to light, but might actually reduce the project’s duration (and cost) and improve the product, as long as everyone understands what’s expected from them and has the right to make suggestions and bring in ideas.
Defining Project Communication
First of all, project communication is the exchange of information that helps achieve the project objective, its very goal. Communication includes instructions and discussions pertaining to the product and its features, project progress, ideas and thoughts. The better the communication network, the more successful the project. Which basically means that investing in communication is investing in the quality of your product. But beware: even project managers who understand the importance of communication sometimes fail to keep it on track. Make sure you talk to them and communicate your priorities well.
Proper communication requires a sender, a receiver, and a medium to communicate the content of a message. Additionally, good communication in teamwork requires honest feedback. Make sure the project manager takes all this into account, as well as the effect that the setting or context may have on the results of communication.
Efficient communication requires that both the sender and receiver understand each other’s roles and responsibilities, as do other parties in the process. Messages have to be structured and univocal. Everyone must be aware of the common goal, the deadline and the scale, but also ready to adjust the process when needed.
Planning Projects Wisely
A project usually consists of sprints. Let’s say one sprint makes up 200 hours, purely for development. Generally, only 10% of this time is planned for communication. But the truth is, proper communication takes a lot more time – and more time still if the team grows or if the theRead requirements for the product aren’t properly explained to the team. And unexpected factors may arise. But not everyone is ready for this.
Read: Secrets of Effective Work Planning in Scrum
I’ve met people who live and work by the words “Less talk, more action.” This approach may work for some ventures, but in development, communication in a team is crucial. Let’s see why. If a task is well-explained and discussed, the chances of finding an optimal solution very fast are extremely high. When you as a client discuss all the risks with the development team, including team members with different qualifications, everyone gets to see the task – and the whole product for that matter – from different perspectives. All this improves all-around understanding of the process and decreases the chances of having to re-do some work or fix bugs in the future. But even if you get all the details about a task, the team still needs time to organize the work. How much backend or frontend development do we need? Who does what, and for how long? These are the questions that always need time to get resolved.
Take Communication Into Account
Returning to the 10% I mentioned before – where does this number even come from? Often, businesses expect it to be true, and are surprised when communication takes up a lot more project time than this. Of course, this increases the price of a sprint. You may have been in this situation – you count on one price, and then you get a bill X times bigger than the estimate. But one thing I know for sure: communication is one of the largest parts of a project, so don’t hesitate to pay for it.
How we do it. In our lifetime as a team, we’ve had our share of clients asking how much time we would need for their teeny tiny project. But, well, define ‘teeny tiny’, right? It’s impossible to get a formula for how much communication will be necessary for every single project. However, there’s no way around it, we have to give the client an estimate. We spend 5-7% of each sprint’s hours for team’s internal communication. This is a statistically proven amount of time for an average project for a minimum team of 4 software engineers, 1 manager, and 2 QA engineers.
My team and I try to calculate the estimate as precisely as possible. The percentage of communication a team will need to achieve the goal depends on many factors.
Badly written documentation or ill-explained requirements increase work time. If the development team gets all the information they need to start planning their sprint, they will be able to do so right away. Be sure to provide full information and structure it well, and make sure the team has understood you.
Bigger teams talk more. A large team isn’t a bad thing. But keep in mind that the more people there are on a team, the more opinions, and the more discussions they will have. Consequently, the communication time will be longer, and the bill larger. Ka-ching!
More complex projects require longer explanation and development times. If it’s a multi-layered project, even the simplest change request can cause a lot of long and heated discussions. Clients don’t always realize that a simple request to change a tiny button or a feature can interfere with the whole mechanism of the product or cause bugs.
Calculating communication time isn’t an exact science. That said, below we offer a broad brush estimate of communication necessary for one sprint – but it’s almost impossible to make an estimate for an entire project. Obviously, it depends on how many people are assigned tasks in each sprint, as well as on the factors I mentioned above.
What Are You Paying For?
I think everyone wants to know exactly what the communication part of the bill for a software development includes. So let’s reveal the mystery and take a look at what developers spend their communication time and the client’s money on.
Grooming
Grooming (or backlog refinement) is the process of discussing all the tasks given by the client. What are the risks, what are the correlations, and what are the business priorities? All the tasks are assigned to different team members who dissect them and research them inside out. They use the grooming time to ask the client questions, think through possible implementation scenarios, and report on the results during the pre-sprint meeting. This way, not only does every team member know what tasks they’re going to work on, including all the details and specifics, but also possible solutions and ways to achieve them.
How we do it. Let’s say my development team receives a set of ten tasks from a client and starts working on them right away. Suddenly, it turns out that a piece of crucial information is missing. What happens next? We should wait for the client to provide additional information and comments. For that, we either stop the development process, or move this particular task to the next sprint, which is already planned out as well. The tasks are snowballing, and as a result, the whole development process takes a lot longer than both we and the client were hoping for.
Grooming, however, prevents the team from taking on a task prematurely. They discuss the task before developing, go through every detail with a fine-tooth comb, and agree on realization approaches. This way, they can guarantee higher product quality and provide a more precise and predictable time estimate.
There are different approaches to grooming. The team manager can discuss tasks with the whole team, if it’s a small one (three to four people) or with several members of a team if it’s mid-sized (six to seven people). Also, tasks can be prepared in small groups if the team has eight or more members – backend, frontend, QA, etc.. Grooming duration depends on the number of team members.
For instance, a backend developer gets an assignment, researches the task, finds out whatever’s missing, and presents it to the rest of the team, adding their suggestions on how to solve it. Now, everyone on the team can discuss them. And again, the more people in the discussion, the longer the communication time. To pre-calculate grooming time for a future project, we take the historical number, i.e. how much time the team spent on grooming tasks like these in the past. Or, if the team is new, it’s possible to go with an average.
Planning
Planning is the process of defining the scope of tasks for the next sprint. It’s when the team members are supposed to be grooming. The precision of the planning relies heavily on the team’s experience. If the team has worked in this particular constellation on a large number of sprints, they will know their speed and how much time they usually spend on communication. Thus, the younger the team, the bigger the difference between their estimates and the actual numbers.
How we do it. As you see below, we have become more predictable from sprint to sprint and decreased the time we spend on communication. Let's take a closer look at the dependency between time planning and the accuracy of estimates. The better the communication, the more precise is the next sprint. And with every sprint, the estimates become more and more precise. As a rule, we plan our scope for the next sprint during the current one. Here you see how a planning/internal meeting in Sprint 0 affected Sprint 1.
As soon as the team gets better in planning, they’ll get a better grasp of task assignment and fulfillment. Mapping tasks improves predictability, improves understanding of tasks, and minimizes deviations in time estimates. Planning takes about 2-3 hours per team member in a sprint, but it still depends on how experienced the team is.
Daily Standups
Daily Standups are daily team meetings held to discuss what’s been done, what will be done, and other things that the team members need to get off their chests. On average, it takes about 15 minutes per person. Thus, to calculate the time necessary for daily standups, multiply 15 minutes by the number of team members by the number of days in a sprint.
Important: For the sake of development, it’s better if all team members must be present during meetings like these. Everyone has to understand what their colleagues are doing, as this improves engagement and motivates each team member. Thus, don’t assume that planning is for managers only.
You Can’t Plan Everything
Truth be told, there are parts of the communication process that we can’t precisely evaluate in terms of duration. Keeping this in mind, remember: it’s totally fine if communication estimates don’t equal the real results, i.e. they exceed the original calculations.
Demo. Of course, the demonstration of the product is vital, but at the beginning of the project it’s nearly impossible for us to know how many times we will have to do it. Demo time is when the team presents the work done during a sprint to the client. Usually it takes about 90 minutes.
How we do it. We usually do the presentation with the whole team present. Clients are often surprised, but we think it’s more effective. This way, everyone is involved and hears the client’s reaction and feedback first-hand. They feel the responsibility and how ‘real’ the project is. And anyway, it’s better to spend 90 minutes, or maybe even more, on this kind of demonstration than explaining the client’s thoughts to everyone individually. On top of that, from demo to demo we ask different team members to present the product – this way, everyone can feel the importance of what they do and how their part is co-dependent with others.
Retrospective. This is the time when the team looks back at what has been done during a sprint, what was good, what can be improved, what they learned, or make an action plan for improvement. Team members can express their concerns, ideas for changes to architecture or flow, or clear up questions they had for the business side. The more answers the team gets during the current retrospective, the better the next one goes. And generally, meetings like these improve team spirit for the whole sprint.
Apart from this, some things can increase not just the communication time, but development time significantly and quite unexpectedly. First, these can be story bugs – they need to be fixed immediately, which takes time. Bugs like these happen when someone misunderstands the task. As you see, if one doesn’t spend enough time researching and discussing tasks beforehand, surprises like story bugs can catch up to them later.
Another thing that can cause problems is introducing new tasks during the sprint. Technically, the number of tasks stays the same, which may leave the impression that nothing changes in terms of time or cost. But going back to what I said earlier, every task needs to be communicated, researched, groomed, and in this case, all this must be done during the sprint.
Communication Rules
I think we’ve established the importance of communication. But the truth is, communication isn’t worth much if it isn’t effective and logically planned.
First of all, you should outline your communication strategy. This means there should be a plan of how to interact, how to communicate with the development team, how often, and in what form. People tend to feel a lot more comfortable and confident when they know what to expect.
My second tip is: communicate in writing. You don’t have to write everything down, and of course you can talk to the development team in an open discussion. But feel free to send out important information in emails or maintain detailed documentation of certain processes so that nothing gets lost.
And finally, be concise. Get straight to the point. In business, there’s usually no time to read through long lines of text. When reading an email, team members scan the text for information relevant to them. The key items include:
- What do they need to know about the issue?
- Does it affect them or what they do?
- Are they expected to do anything?
- If yes, when?
When communicating tasks, don’t forget to mention who’s responsible for them, when and how do they have to be completed and delivered, and what happens next. Providing only the crucial information will help you save time and work more efficiently.
Even though it seems like a difficult thing to do, investing sufficient time into well-structured communication is always better than fixing what has been done (or not done) due to a lack of it. As you see, it’s hard to calculate communication time for the entire project, but, by taking baby steps, the team can make an estimate for a sprint, taking into account the number of team members and the sprint’s duration. Every team member should know exactly what to do, how to do it, and how the results of their work correlate with what everyone else is doing. This way, they will work efficiently and stay motivated, without wasting time on extra questions and explanations.
If the communication between the client and the software development team, or even within the team, is insufficient, problems can arise when the team starts working. Time is wasted on explaining or on waiting for the poorly explained tasks to be completed. So remember: the better you plan, the better your chances of meeting your estimated goals and deadlines.
This article about Project Communication is written by Iryna Meshchankina - QA Lead at Django Stars. Originally posted on Django Stars blog.
Top comments (0)