PM Guide

Project life cycle

How to prepare a successful project kick-off

author: Anna Dąbkowska

Project kick-off is more than just the kick-off meeting (the first official meeting between the client and the project team). It also involves laying the groundwork for a successful project, and a lot depends on us being well-prepared before we kick off.

Discover your starting ground

The kick-off meeting shouldn’t be the first meeting with the client. Before you start work on the project, pre-sales experts find out what the project is about, what the scope is and what technologies are involved. Once all this is clear, you can find the right team and proceed to kick-off.

If there are still questions left, run a workshop. It can be anything from a one-day scoping session (letting you investigate the client’s idea for the product) to a full-blown 5-day Product Design Sprint, during which a team of Product Design and Tech consultants solve business problems through design, prototyping and testing ideas with customers. It is crucial to understand the main idea for the project and the client’s expectations for it.


Once you know all about the pre-sales process, you can sit down to do some research. Find out who your client is – including their background, previous endeavours and achievements. Who do they cooperate with? What does their company do? In what industry? If the product you’re going to be working on already exists, find out how it’s doing, whether users like it or not and why. Test it yourself. This is going to be your bread and butter for the next few months, if not more, so you should get to know it.

Having done your research and spoken to the people who handled the client and their idea before you, you can write down the most important issues that you’re going to be dealing with, i.e. the challenges that your team might face and the risks they might entail.


While doing research on the client and their project, you will probably come up with a lot of questions. That’s good – write them down, as they will be the basis of the kick-off meeting. Make sure that you’re not going to be asking anything the client has already answered.

At this point, you should already have a team assigned to your new project. Get them on board of what you’re going to be doing by sharing all the information you have. Go through question points, risks, and challenges together. You will probably have to run a longer meeting to do a reestimation of the effort the project will entail.


Only 10 minutes left until the meeting that will start your (hopefully) fruitful cooperation with the new client and team. So what can you do to make sure everything goes as planned?

Definitely draft an agenda for the meeting so that everyone knows what you’re going to be discussing. If you have a list of questions to the client, you can send it to them beforehand, to allow them to prepare exhaustive answers. This is especially important if you want to touch upon complex topics or request access to tools and data.

On the day of the kick-off, you can have a quick preparatory meeting with your team to make sure that everyone is on the same page. While Project Managers facilitate a lot of meetings, they are not the only points of contact for clients, and they need to depend on each member of the team as experts in their domains.

Lastly, take notes throughout the meeting or ask someone to help with that. It’s easy to miss important details during an intense and lengthy meeting, and these notes will help you plan your next steps in the project.

Questions to ask yourself in the first weeks of the project

author: Filip Kozłowski

Starting a new project is no easy thing – there’s a lot to take care of, and you have many decisions to make and problems to watch out for. Bad choices or mistakes may go under your radar, and cause problems later on – problems that could have been prevented if addressed early. Here’s a list of questions to ask yourself when making sure that you and your team are off to a good start.

Are we catering to the actual needs of the users?

The only end result of the development process that really matters is the value brought to the end user, which will make the application attractive in their eyes and cater to their needs. From the very first weeks, you should make sure that your team understands what this means in your case – and aim to deliver exactly that. You should understand who your potential users are and what drives them; otherwise you are risking ending up with a product that has slim chances of achieving success.

What is your client’s role in the project?

In commercial projects, the client will be your window to the world – getting enough information about their vision, mission, and goals is vital to your success. To make the cooperation smooth, it’s good to understand what role the client plays in your setup. Will they work with you on a day-to-day basis and supervise the progress to the verge of micromanagement, or will their activity be limited to conveying a high-level vision and requiring your input in working out the details?

As with most things, there is no right answer as to what the client’s involvement should look like – but if you observe that it is inadequate for the project, it’s important you address this as early as possible, expressing that you want to redefine the client's presence to make it maximally productive.

Is your velocity reflecting the estimations made before the project started?

Almost every project will have the effort related to delivering its scope roughly estimated, in order to establish a timeline and the necessary budget. It is crucial to monitor from the very start how quickly the development team progresses in comparison to that estimation.

If you see that the team needs more time than expected to deliver the first few tasks – this may forecast a similar tendency for the rest of the project. It’s crucial to communicate it openly to the client the moment you notice it, in order to give them a chance to react – either by adjusting the scope of the MVP, extending the timeline or finding additional funds. Wishful thinking about “catching up in the next Sprint” is a classic error that has put many releases at risk.

Do you understand how much you can spend, and where the budget comes from?

Avoiding conversations about money out of politeness is the kind of thinking that causes projects to capsize. Knowing how much your client can spend on a project is crucial to understanding whether delivering the planned scope is feasible and if the work is prioritised correctly. With a tight budget for an MVP, you have to be extremely wary about exceeding the planned timeline. If you are working on adding new features to a product which already exists and you have a limited amount to spend every month – you need to know whether you can afford to temporarily upscale the team, should the situation call for it.

Similarly, understanding where that money comes from can be helpful in anticipating the challenges ahead. For example, if your client is actively looking for investors, they may need to showcase the product, and the financial situation may shift dynamically based on whether they receive funding or not.

If you feel like you are in the dark, or have very limited insight into this – ask your client if they can share more information, while also telling them why it might be useful for you.

Is there any opportunity for you as a PM to step up and provide additional help?

Being a Project Manager means you’re a jack of all trades – you’ll fill various roles depending on the team you are assigned to. The first few weeks on a new project will most probably be a time you spend on setting up tools, establishing the workflow, and so on. But in addition to that, you can get the lay of the land and see where your assistance is needed the most.

Maybe your PO’s time is very limited, and you can assist them in refining the Backlog. If you are working with a team of inexperienced developers, you may decide to dedicate some time to coaching them to be more self-reliant and able to take ownership of their work. Whatever the specifics of your project are, you are very likely to find something you can do to remove the impediments others are facing and make their work more efficient.

Is the team cross-functional?

For the project to run smoothly, all tasks required to complete it should be within the competences of the team (a must for efficient work, according to Scrum guidelines). However, in reality, you will find that your team may require external assistance. Devops may have to come to your rescue after a failed deployment brings production down, your fresh-out-of-juniorship regulars may not have enough know-how to make a decision on app architecture, or legal requirements might force you to seek security-related consultancy.

Asking others for help is nothing bad, but it may not be the most efficient way to go. If you find that your team is blocked waiting for other people’s input, you may want to either try to bring the specialists on board, or see if current team members can broaden their skills to be able to overcome the challenges you are facing.

Do you track risks in your projects?

We do not want to think about the potential bad outcomes of our actions, but they tend to happen regardless of our wishful thinking. Having a discussion about the risks in your project is something that will pay off in the long run, as the team will be able to plan how to counteract them. There are techniques both for identifying risks, and for writing them down and quantifying them, from a simple assessment on a 3x3 matrix according to their impact and probability, to a detailed SWOT-TOWS analysis. Choose whichever one you find the most suitable. The important thing is that this should not be a one-time activity. Rather, you should revisit it every now and then to see if the register you’ve created is up to date.

This is all the more valuable if you make it transparent to your client, making them part of the process. While it may be your intuition not to speak to them about it, this attitude is an example of wishful thinking. If you assume the risks may come true, then discussing them openly is part of being prepared for facing them.

Do you have Definitions of Done and Ready – and are they adequate to your needs?

Gathering requirements is vital if we want to make sure we deliver the right product, and gathering them at the right moment helps us do so efficiently. Establishing what we need to know to estimate a task and start working on it (which is what “ready” means) should be done early on, to make the first iterations as fruitful as possible, and establishing the right cooperation with the Product Owner from the start, instructing them on which information is crucial for the team.

Similarly, criteria which need to be fulfilled to consider a piece of work as finished (or “done”) should be laid out at the start of the project, and made visible to everybody involved. Both definitions should be a result of a team-wide discussion. You can use an existing template as a starting point, making sure it’s adjusted to your needs. Take the things specific to your project into consideration. You might need specific data to estimate how challenging building a certain feature will be, or to keep unusual security requirements in mind before checking something off the list.

Sprint 0

author: Sebastian Grzelak

To understand the concept of Sprint 0, or “Technical” Sprint, we should recall how the Scrum Guide defines a Sprint:

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", usable, and potentially releasable product Increment is created.

According to the above statement, orthodox Scrum users will always claim that Sprint 0 is not a part of Scrum and they will be right, because during Sprint 0, the development team will not deliver an increment – which doesn’t mean that they won’t deliver value. It also doesn’t mean that it’s not an Agile practice, because as we read in the Agile Manifesto:

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It’s the development team’s autonomous decision to start the project from Sprint 0, based on how they see the purpose and benefits of running one. The team has the privilege of organising their work in a way that will maximise their efficiency.

The main goals of running a Sprint 0:

  • Understand the scope of the project in order to identify potential dependencies.
  • Design the solution and architecture.
  • Shape the Product Backlog for the MVP version.
  • Estimate the MVP.
  • Refine the Backlog items for at least the first Sprint, so they are clear, concise, and most importantly, actionable.
  • Prioritise Backlog items.
  • Prepare a roadmap for the MVP.

If Sprint 0 fulfils the above objectives, then it is highly probable that the development team will start delivering increments with high velocity, because they will be equipped with deep knowledge about the scope of the project and will be self-organised.

How to run a successful Sprint 0

We usually start from a discovery workshop during which the client presents us with the business objectives, vision and goals. We work together to convert business requirements into Backlog items and outline the MVP.

The next steps need to be taken by the development team and involve:

  • Spikes: short experiments with the purpose of finding out if a particular solution or technique will work, or how complex something is going to be. Usually, only developers participate in spikes and they do pair programming to research a specific topic.
  • Benchmarking sessions: the development team analyses the benchmarks for the client’s idea to gain an understanding of the client’s brand and market.
  • Solution design sessions: the team designs application architecture and shapes the solution from a technical perspective.
  • Planning poker sessions: estimating the Backlog items included in the MVP and informing stakeholders about how long the development could take and what budget it is going to consume.

The results of the above methods are documented in a project’s knowledge base and in the descriptions of Backlog items.

What are the deliverables of Sprint 0?

At the end of Sprint 0, the development team should deliver the following items:

  • Solution architecture diagram and its description (including identified dependencies),
  • Roadmap for the MVP,
  • Product Backlog with prioritised and estimated items for the MVP,
  • Refined Backlog items for at least Sprint 1,
  • Benchmarks.

Sprint 0 – under what circumstances should it happen?

It’s possible that Sprint 0 will be unnecessary for your project, because the scope of the project has been described carefully by the customer and Product Backlog items have been actionable from the start. Moreover, Sprint 0 may not be suitable for less complex, short projects.

When should you use a Sprint 0 before development starts?

It should always be an autonomous decision of the development team to run a Sprint 0. The following prerequisites can point you in the right direction:

  • Complex project with an unclear scope,
  • Long-term project (6-months+),
  • Project with Backlog items described only from a business perspective without technical input,
  • Project without a clearly formulated Product Backlog.

Why it is essential to understand the why behind your project

author: Agnieszka Stanisławska

Project Managers focus on the delivery process, but in the heat of the moment, chasing deadlines, keeping an eye on the budget and trying to find the best solution to optimise the project scope, they may forget to stop and consider the purpose of their work.

Too often, the end-product does not bring satisfaction, even if it’s delivered within budget and according to specifications. Why is it that seemingly successful products fail to bring in profit or never gain traction?


Understanding why we do what we do during product development is crucial. The why is a directional indicator for setting smaller targets and staying on course when we need to make decisions. Being aware of the why allows us to develop a product that is a useful tool that will bring value to stakeholders.

The why answers the most important question for the product: “why are we building it?” It guides the decision to begin work. It is also a starting point for defining the goals we want to achieve in the short and long term.

The why also includes the core values that we should pursue through product development. For each client, it can be something different and it is up to us, as Project Managers, to understand what is the most important from the client's perspective. This understanding should be achieved in cooperation with the client.

Do we have an influence on the why?

Understanding the why is the first step to providing value to the client in the form of solutions that address the client's problem. If the client is not sure themselves, we need to ask specific questions and help them realise what they are striving for. Core questions we should ask are:

  • What value does the product offer to customers?
  • What is the target group of the product?
  • What needs of the target group does this value fulfil?

The sooner we start talking about it, the better we will be able to define the objectives resulting from the why. We usually don't have a say when it comes to defining the why, but we have an influence on its implementation.

Why should we think about it?

If the why is our guiding star, and goals are the checkpoints that verify whether we are heading towards it. We do not always have a real influence on how the next step will be defined, but what we can and should do is to regularly check and verify whether we are getting closer to its implementation. Architect your project in a way that will validate your direction with each iteration, testing added value as early as possible.

How to use your awareness of the why

As PMs, developers, testers or project team members, we feel like experts in specific fields. We know our strengths and how to use them. However, our expertise is not always the right answer to the client's problem. That is why we should adjust our solutions to clients’ needs and this is called consulting mindset. It is considering customer problems to put forward solutions that will address their needs, rather than using the solution we are good at. This approach allows us to enter a higher level of commitment and foster better cooperation. This cannot be achieved without the knowledge of the client's problem defined as the why.


author: Sebastian Grzelak

Accurate estimations in software projects are one of the biggest challenges of the software development world. Some say that an accurate estimation is like the Holy Grail – you can never reach it. Improving the estimation process is a continuous challenge.

Why do we estimate projects?

You may say that estimations are not Agile and if you work using Agile principles, you shouldn’t estimate Product Backlog items. However, remember that the Agile Manifesto states:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

In order to achieve the above, each team should self-organise and choose the tools and methods that help them reach this goal. Moreover, we don’t live in the ideal world where projects are not limited by time or budgets. In order to effectively manage a client’s budget and timeline, you need to estimate tasks, and it doesn’t matter what kind of scale or method you use for that. Be Agile, and choose what suits you and your team best.

Why estimate IT projects?

Estimations help in a number of ways.

Business perspective:

  • Budget tracking and controlling,
  • Tracking deadlines and milestones,
  • Planning marketing activities,
  • Keeping all stakeholders in the loop,
  • Tracking ROI.

Product Owner’s perspective:

  • Efficiency optimisation,
  • Impact optimisation,
  • Value maximisation,
  • Backlog ordering.

Development Team’s perspective:

  • Planning daily work better,
  • Less stress in a project – less stress for you,
  • Understanding velocity and capacity – better Sprint planning,
  • Improving effectiveness.

How do we estimate projects?

Relative estimation is one of the best approaches. When we estimate tasks or user stories not separately, but by comparison or by grouping items of equivalent difficulty, we tend to get more accurate results. Research shows that people are far better at relative estimation. If there is a point of reference that can be used to estimate a task’s difficulty in terms of effort, then it is much easier to assess whether this task is twice the size of the other task, etc.

The main advantages of relative estimation are as follows:

  • It is conducive to teamwork,
  • The estimates don’t age,
  • The estimates are a measure of size in a pure form,
  • Teams can estimate more quickly,
  • Relative estimation avoids some of the pitfalls associated with estimating in general: seeking unwarranted precision or confusing estimates for commitments.

Relative estimation in practice

Now that we know what relative estimation is and how beneficial it can be, let’s learn how to use it.

First of all, you need to remember that estimation is a team sport, so in your estimation session, you have to involve the whole team working on the project. It is critical, because each team member brings in a different perspective on the work required to deliver a task. Developers must understand that they are not only estimating the coding – they estimate all the activities implied by the team’s Definition of Done. It’s important to include the effort required to refine the task, review the code, or test the solution. Every stage of your process has an impact on the effort needed to complete the task.

Remember that you always estimate effort, rather than complexity or anything else. Consider two very different assignments:

  • Hammering thousands of nails in,
  • Heart surgery.

The complexity of these two activities is totally different. The surgery is much more difficult and requires expert knowledge, while hitting nails is pretty easy and everyone can do it. However, when we consider effort and time, the tasks will be almost equivalent.

Whatever scale you use for estimation (points, ideal time, T-shirt sizes, and so on), it will always measure effort, and effort means time.

The whole team has to select a base story/task that will be used as a reference to estimate remaining tasks. The base story is the smallest task the completion of which is trivial to the whole team and which would require very little effort to implement. The base story is always project/product specific. It is impossible to select a generic base story that could be used in different projects as a reference.

When the base story is selected and approved by the whole team, you can proceed with estimating the rest of the Backlog items. The more tasks you estimate, the more reference points you will have, and the estimation will go faster.

Is adjusting estimates a good practice?

Yes. We don’t live in a stable environment, and the project’s environment changes dynamically. The Scope is not constant, because the business circumstances are always evolving. Initial estimates will become outdated. That is why we must follow the three Scrum pillars: transparency, inspection and adaptation.

This means that we need to keep the project Backlog transparent for the development team, as it will allow them to estimate better. Estimates should be frequently inspected and modified, if needed. Product Backlog item estimates should be re-evaluated during each Sprint planning, so that the Sprint Backlog items have the most recent estimates. Moreover, during Product Backlog refinement, all items that are updated or added should be (re)estimated by the development team.

How to conduct a remote Sprint planning meeting

author: Pola Mikołajczak

There are no definite answers for such a question in a complex environment. But let’s take a look at the issue from the perspective of a reasonably big Scrum team. This story is based on true events.

The context

We were developing a new product, innovative in a few ways, but not fully R&D. We decided to start with the Scrum framework, slightly adjusted to our needs.

We had a Product Owner on the client’s side, and a Scrum Master on the software house side. We used two-week Sprints, with 90-minute slots for the planning of each Sprint. The development team consisted of six developers, three on our side, three on the client’s, plus a QA specialist. The team was fully remote.

We had to overcome several challenges. While planning in a 4+ person team, we often need smaller discussions, but this meeting needed to be remote. Additionally, the team didn’t have enough time to estimate properly. They didn’t even have the time to digest the plan, stories, goal, etc.

We learned that, to create a good plan for the next Sprint, we needed:

  • A shared understanding of business priorities – what we should tackle next (that’s the PO’s job).
  • Estimated development tasks that would cover the scope of our business goals (we use grooming meetings to achieve that one).
  • Awareness of the current state of the project – what is finished and working and what is not.
  • Awareness of our capacity for the next Sprint (days off, holidays, etc.)

The process

Through this experience, we established a step-by-step planning process, starting with a preparation phase:

  1. A grooming meeting is held a few days in advance. The development team and the PO had a chance to discuss features (user stories) that will be the next priorities. During or after the grooming, the features are split into development tasks.

The remote Sprint planning meeting agenda:

  1. The PO communicates business priorities. This is an early version of our future Sprint goal.
  2. The development team makes sure all the priorities are broken down into development tasks. That’s where we need close cooperation between team members to make sure we’ve thought about all dependencies. It’s a good practice to note down dependencies or mark them in Jira – we will need this information later. At this point, our solution is to split the meeting into separate calls in smaller groups – sometimes feature-focused, sometimes with subject-matter experts.
  3. The development team checks its capacity.
  4. The dev team fits the tasks into the capacity to see if we have some room left or if there is too much to do.
  5. Velocity check. Based on historical data, the team assesses how much they can take into the Sprint. The development team prepares a suggested Sprint Backlog.
  6. The first version of the Sprint Backlog is presented to the PO. They may change the order of priorities or ask to replace some items – just as there are dependencies on the technical side, there are some on the product side as well.
  7. When we have the buy-in for the Sprint Backlog, the PO suggests the final wording of the Sprint’s goal.
  8. It’s time to start the Sprint in Jira and discuss the exact plan for the next few days. Do we have any specific dependencies in this Sprint? Is there a risk somebody will be blocked?
  9. Now we are ready to finish the planning meeting and close the call. Your team has just accomplished something great – thank yourselves for the meeting and for the attention you paid to your work. Now you have a shared goal for the next Sprint.

Key takeaways

Take your time to prepare for the Sprint planning meeting. This is even more important when the meeting is remote – on a call, all impediments caused by insufficient preparation have double impact. Be aware of what kind of input you need – having time for preparation is futile if you are not sure what you need to prepare for.

Share the main agenda and the goal of the meeting in a place the development team can easily access. Forge a clear and shared understanding of the expected outcome of the Sprint planning. It’s best to have a goal written down at the beginning of the meeting and make the development team (not the PO, not the SM, not some manager) see this as their goal for the next 90 minutes. You can use Sprint planning questions suggested by Lyssa Adkins in Coaching Agile Teams.

This flow worked in our environment and helps achieve better results with less stress. Remember to observe your environment and team first. Then, you can experiment and see what works for you.

Risk identification – using the pre-mortem approach as part of the consulting mindset

author: Mateusz Krawczyński

One of the key aspects of being a great consultant is the ability to identify opportunities or threats for a project, while helping teams come up with a clear vision on how to act when these predictions turn into reality. Great consultants are also brave enough to openly discuss even the most difficult problems and have ways of using teamwork to find the right solutions. The formal name for this type of Project Management activity is risk management. A very neat and simple risk management technique called the pre-mortem can help you achieve better results and thrive as a consultant.

What is risk?

For many people, including Project Managers, risk is a threat, something that might disrupt our endeavours and put project success at stake. However, the definition proposed by the International Organization for Standardization in the ISO 31000 standard guide defines risk as an “effect of uncertainty on objectives”. The effect can be good or bad, and is caused by uncertainty – something that is not known for sure in the project. From this perspective, positive events and opportunities are also risks. From now on, we will focus on the pessimistic scenarios, but bear in mind that there is more to risk management than just avoiding problems.

Introduction to pre-mortem thinking

Think for a moment about the beginning of your last project. What are the feelings that accompany such moments? We often experience excitement, feeling of purpose, or empowerment, which are positive emotions. We talk about goals and how great it will be when the project succeeds, how the revenue or other results will be turned into even more features, opportunities and plans. We set ourselves up to succeed and don’t consider failure as an option.

Exercising such foresight can be one of the most vital points in a project’s lifetime. The first true test for the team. Will they be able to spot the obstacles that might stand in the way of their goals? Many organisations focus only on the happy path, blithely ignoring risk factors. Fortunately, there are easy ways of solving this problem. One of them is the pre-mortem workshop technique.

With the pre-mortem approach, the whole team will participate in identifying problems or risks, and then openly discuss them. This very simple brain-storming technique is highly effective when conducted at the beginning of the project (e.g. as part of the kick-off routine) or before major project phases, but there is no reason not to perform it on any other occasion.

The basic concept of the pre-mortem can be summed up in one sentence: get your team together and perform a session of doom. Ask them to imagine that the project has already ended and everything has gone wrong. This approach encourages team members to voice their fears and concerns early on in order to prepare for the future. It is a simple twist on the usual way of thinking about risk identification. Gary Klein, in his article about the pre-mortem approach published in the Harvard Business Review, says that research (...) found that prospective hindsight—imagining that an event has already occurred—increases the ability to correctly identify reasons for future outcomes by 30%.

How to run a pre-mortem workshop

You need three things to run a risk identification session: your project team (ideally including stakeholders), a whiteboard (physical or virtual), and at least one hour of time. Here is an example agenda that you can use:

  • [5 min] Introduction to the pre-mortem technique
  • [5 min] Pre-mortem goals
  • [10 min] Silent brainstorming
  • [15 min] Sharing
  • [15 min] Discussing, mapping and clustering
  • [5 min] Wrap-up

Start the meeting by introducing the basic concept of the pre-mortem and the agenda for the workshop. Ask all attendees to imagine the project has already finished. What went wrong? If you worry that the participants of the meeting might not be as imaginative as you would like them to be, use these supporting questions:

  • What went wrong?
  • What did you fear would happen?
  • How did it end up so bad?

Don’t try to resolve the issues the team comes up with during the brainstorm. And remember: brainstorming means that even the least probable ideas are discussed.

Let the team silently brainstorm their ideas using virtual or physical sticky notes. Afterwards, encourage them to share their ideas openly and discuss the reasoning behind them. During the final part of the meeting, all the cards should be cooperatively sorted, groomed and clustered. To maintain focus and stick to the agenda, request that participants identify up to 10 or 15 risks which they find the most important.

During the last part of the workshop you can try to answer questions such as:

  • What do you think is the reason behind this failure?
  • Will it severely impact the project?
  • How likely is the failure to occur?
  • Can we fix it or is it beyond our reach?

By doing all this within an hour, you will spark a valuable discussion, find hidden problems, and empower the team to speak openly and act when they see obstacles, impediments and risks. In our experience, this technique creates a safe space where all team members can raise their concerns and fears. With proper facilitation and moderation, the team can unravel the reasons that cause those ‘gut feelings’ and turn them into valuable insights. Open and transparent communication of risks (positive and negative ones) helps us build trust and ownership within the team. We believe that being a great consultant does not mean you know all the answers, but that you dedicate yourself to finding ways of unlocking the potential of the people you work with.

Definition of Ready – how to save a lot of time by solving the problem of poorly described tickets

authors: Lucyna Spławska & Sebastian Grzelak

Imagine the nightmare of every project team: all tickets in the Sprint are completed, but the feature does not work. Unfortunately, such a scenario is not entirely uncommon, and it often boils down to inaccurate task description. When we balance between poorly described tasks, we need additional clarification meetings or calls during a Sprint, and exhaustive, detailed lists of requirements which tend to kill developers’ creativity.

How to make sure that a task is ready to enter a Sprint and the information provided in its description is just enough for developers to understand the scope of a task, but won’t impose an implementation? Use the Definition of Ready, taken from the Scrum playbook.

Ready for what?

First, let’s start with the DoR (Definition of Ready), which is a set of requirements that need to be fulfilled for each task in a Sprint. If a task is described according to the DoR, the team can see what needs to be done and how much effort it will take to complete the assignment. Moreover, it increases the predictability of Sprints.

The problem we faced

To be more transparent and to illustrate the idea of the DoR, let’s use one of our projects as an example. A lack of information flow caused a drop in our team’s effectiveness. It led to a situation in which the team needed additional calls to clarify what should be done within tickets, which impeded their velocity. Despite constant discussion, there were still gaps in the delivered features, which were usually rejected by the Product Owner.

The tickets were completed, but the feature itself was not working. The cause was the lack of a type of validation, relation to other stories, tips on connecting with the backend, and other crucial elements.

The solution

We took a closer look at our delivery teams and compared what information was available in a ticket. After analysing a number of examples, we came up with an initial Definition of Ready template and implemented it in 31 projects, which was around 30% of all active projects in Netguru at the time.


After a few weeks of using the new DoR, we started seeing changes in the projects. There was less confusion around the scope of tickets, which also meant developers weren’t wasting so much time on additional calls. If we assume that each developer sacrificed 30 minutes of their work time every day for these calls, and multiply it by four people (as was the case for the team in the story), five days, and four weeks, it adds up to over 40 hours per month.

By providing key business requirements, we also mitigated the risk of developing a feature with misaligned business value. If we do not include information about the business need, a developer might make certain assumptions and implement a feature in a way that seems most logical to them. An individual’s way of thinking is not always in line with the end user’s needs and product concept. On the other hand, flooding a developer with a long list of must-haves will not only undermine their motivation and ambition, but also move the focus away from the main purpose.

With our new DoR, delivered tickets reflected reality. Once a ticket was done, there was no coming back, the feature was up and running. Our velocity increased due to the time saved and a constant information flow. It took about four weeks before the whole team adopted the new ticket description template, but it got smoother with time. Increased trust within the team and a shared understanding of the current scope was an additional benefit.

DoR in a nutshell

This is the list of information to include in a ticket. These ideas can be modified and adjusted to your project’s needs.

  • The user perspective. It is always good to start with a user story just to feel like an end user for a moment. When creating a user story, remember about outlining the type of user (e.g. an admin or front user), the specific needs of this user, and how they can be fulfilled by the product you are building. For example:

As an admin, I want to see detailed user information, so that I can answer all the questions asked via the customer service desk.

  • User flows. It is always appreciated when a user flow is presented in the ticket. If you are not able to present the whole user path, at least make sure to add the screen before and after. Giving a broader context to a ticket will help the developer implement the right feature simply because there will be no need to investigate. Often, the best way to present the user flow is a diagram (e.g. using BPMN or UML).

  • Why the task needs to be developed. Write down why this feature needs to be implemented and what are the implications for the whole product. This helps us to get a business perspective and understand the product better. Sometimes, it also allows us to spot contradictions or bugs. If possible, remember to add screenshots, designs or videos – anything that could help a team member understand a task.

  • Acceptance criteria. These are the specific requirements which need to be met for a task to be marked as completed. They can include values, colours, shapes, actions, or any other defined attributes. In design projects, this will be a section for designs or wireframes delivered by a PO.

  • Technical requirements or recommendations. Mark any extra technical aspects that need to be solved or implemented. Examples include an additional security layer, an external API integration, a format of data sent, or custom gems.

  • Testing. Testing scenarios are quite time-consuming, but definitely worth the sacrifice. In order to prepare this section, follow the four steps below.

    • Scenario: action performed or condition met
    • Given: the user logs in as a user type A
    • When: user account is verified
    • Then: user should be able to submit a request

Why does having a DoR help?

Setting and applying a DoR boils down to establishing standards within a project. By clarifying what user stories should look like, we reduce the amount of time spent on clearing up details during the Sprint. Stories which are ready should be clear, concise, and, most importantly, actionable. Only tickets that meet these criteria should enter the Sprint.

What may impede the process of introducing a DoR?

Introducing a DoR takes time. A DoR, once set, needs to be developed and mastered as a project progresses. It can take up to a few weeks before you see the benefits from introducing it. Also, the lack of immediate effects can be discouraging to Agile teams used to quick, tangible results.

The DoR is strongly dependent on the Product Owner’s technical knowledge, as well as the team’s experience and engagement. One person is not able to provide the full description. Business background and user perspectives can be provided by a PO, but the technical part needs to be filled in by a developer or a QA expert. Please note that the PO is responsible for setting priorities and creating tickets, but the whole team is responsible for ticket descriptions.

A lack of consistency among team members can be a challenge, particularly when the PO already follows a set of rules and guidelines, but a few team members feel more comfortable clearing things up on a quick call.

If you are unsure whether your team understands the DoR, run a test. Create a survey using Google Forms with a simple request: give the Definition of Ready established in the project you work in. Check the answers and celebrate if the responses converge. If not, set up a meeting and write down your Definition of Ready. The sooner you have it, the less time will be wasted during development.

Project roadmap

author: Olga Andrzejewska

A roadmap can sound huge and scary. Your project is short, there isn’t much scope, so why would you need one? Or maybe the scope changes so fast that it doesn’t make sense to prepare a roadmap, because you would be spending too much time on reworking it? So when do you really need a roadmap? The answer is simple: always.

What is a roadmap?

It’s a strategic plan containing goals, milestones and any major steps we need to take to get the desired outcome. It’s mostly high-level but shows what needs to be delivered and when to meet the deadline. You can have epics, tasks, budget information and all of that divided between team members – it all depends on the project and its environment. The roadmap is a valuable source of information for everybody. Whether you’re a Project Manager, Product Owner, developer, or one of the stakeholders, it should let you see the bigger picture.

Why do you need a roadmap?

You will get lost without it. It’s so easy to get caught up in day-to-day work. But no matter what, you should always stay focused on one thing: value. You can call it business value, the desired outcome, or goal. Whatever you choose, every decision should be made with value in mind.

The roadmap helps you do just that. It keeps you focused, gives you a context to work within, and shows you dependencies within the project. Also, it helps you keep things under control. And when you want to make huge changes and reorganise everything, your roadmap will hold all the information needed to put in into a new, better order.

How to start?

No universal recipe for preparing your own roadmap exists. How mature is the product you’re working on? Is it just a concept or a live product? Who will use the roadmap? Just the delivery team? Stakeholders, the Board, or investors? What information is crucial? What elements do you have to include to make strategic decision-making easier? What about your budget, deadline, and division of labour? The answers to these questions will define what your roadmap should look like.

Focus on the general vision and defined metrics. A roadmap consists of two main things: the final goal and the road towards it. Sometimes, you will need to make assumptions about how long development will take, what steps will be needed, and so on. A roadmap is never set in stone. We want to be Agile, so changes are our bread and butter. But that’s also why it’s good to compare assumptions (or estimations) against reality as often as possible.

How to prepare a roadmap?

One thing that you will always have to do is prioritising. It doesn’t matter whether you’re on a super limited budget or are just testing some solutions and there is no deadline. Having priorities is always the best idea. They will get you to where you want to get faster and motivate you, because you will be able to easily observe your progress.

You will most likely need to track your budget one way or another. Why not kill two birds with one stone? If you have a timeline and know your costs, it’s easy. Just add the correct amount for each week, month, quarter – whatever fits your project. If your budget is fixed, it will show you how much you can do, or it will help you switch priorities. If not, you will get the final cost estimation. Having costs in mind will also help you set the right goals and milestones.

Costs, time frames, milestones, and priorities are very important. But what is the ultimate goal of a roadmap? It’s communication. Every team member and stakeholder will use your roadmap in a slightly different way, so focus on indisputable facts. This document will be always available for all and frequently updated, which will save you time and prevent misunderstandings.

What tools to use?

There are plenty. Jira has a special extension just for roadmaps, and so does Confluence. If you use Confluence to keep information about your project in one place, take advantage of the full potential of this space. If you need something fancier, try using a dedicated tool. You can even use Excel or Google Sheets. Focus on content more than fancy features.

A roadmap, just like your project, is a living organism. It will change and that’s a good thing. You can customise it, approach it from a different angle, use different tools, and show various data sets. The only thing you can do wrong is to not have it at all!

Daily Scrum

author: Paulina Chmielewska

Daily Scrum (or, less formally, the daily standup) is one of the most valuable Scrum events. It happens every day and takes 15 minutes. The main goal of the Daily Scrum is to improve the team's communication and to make sure that all team members have the same perception of the project. It takes the form of a chat among the development team, focusing on the current situation in the project. You can also use the following recommended questions:

  • What have I accomplished since the last meeting?
  • What do I plan to do for the next meeting?
  • What impediments are in my way?

Answering these three questions helps with planning further work and finding potential risks. Additionally, commitments made before the whole team are much more motivating than a commitment made before the boss or client.

Good practices

Stand up. If you work with an on-site development team, standing up during your meeting allows team members to stay more focused and prevents them from zoning out.

Fifteen minutes and that's it! According to Scrum rules, a daily standup should take 15 minutes or less. Having that time frame makes the meeting short and intense, preventing team members from diving into too much detail. A time-box for each team member could be useful.

If your Daily Scrum regularly takes more than 15 minutes, consider reviewing your Sprint goal. With an unclear Sprint goal, the discussion may become too broad and lose focus on the expected outcome. Also, you can start using time management tools (such as Team O’Clock).

Have those meetings at the same time and place every day (or the same time for remote teams). The best time for a Daily Scrum is in the morning, when team members still remember what they did the day before, and can plan for the upcoming day. Always start the meeting at the same time, even if the whole team is not there. If you keep waiting for the tardy ones, more team members might stop showing up on time, thinking that there will be a delay anyway.

What to avoid

Don't transform a daily meeting into a reporting meeting. Dailies are treated as a discussion between all team members. It is important to remember this – otherwise the meeting will transform into something unpleasant for the team.

The Daily Scrum is not a planning meeting. Focus on answers to the three main questions and try to avoid covering more complex topics. Short but intense is the rule of thumb. If you see someone start speaking about a bigger topic, suggest that they finish discussing it after the daily.

Do not limit your communication only to standups. Team members need to know that they can communicate all the time, not only during scheduled meetings. Create a communication channel where all team members can freely talk with each other. Also, if you feel that there isn’t enough space for tech talks, you can always arrange post-daily meetings. Try splitting your team into smaller groups to enable them to tackle more technical subjects.

Iteration review

author: Kamil Puk

The iteration review is often greatly undervalued. Some teams still skip it, even though this meeting fuels the two essentials of cooperative software development: building a product that fits the market, and promoting the ownership mindset within the team. Let’s dig into the goals, methods, tools, and popular challenges in conducting an iteration review that is good, or at least good enough.

The main goal and side goals: which is which?

The goals of a review cover three main areas. The review enhances the understanding and ownership of the business value of the solutions delivered by team members. It allows stakeholders to understand the new increment better and provide their input. Finally, based on the feedback, a review allows the team to align future development plans with business needs more clearly, and to engage a wide array of stakeholders into building the value.

A simple definition of the Iteration review is provided by SAFe (Scaled Agile Framework):

The Iteration Review is a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress.

The Scrum Guide adds a vital cooperational element:

Sprint Review is held at the end of the Sprint to inspect the increment, (and the) presentation of the increment is intended to elicit feedback and foster collaboration.

There is another necessary part: empowering everyone on the team to participate in presenting the increment. The review can enhance their will to understand and fully own the solution they design, build and operate.

The basics: who and what

The review is usually organised either by a Project Manager or a Product Owner. Most likely, it means they are responsible for finding the time and space, as well as for making sure that the meeting brings value to the organisation.

It’s useful to define what constitutes a successful review, even though each team adapts the general agenda to their own needs. Some of the key elements are:

  • A short review of action items from previous reviews: what is done, in progress, or blocked. Usually delivered by the Scrum Master or Agile Coach.
  • An update from the business environment – from the Product Owner, Customer Success Team, or CPO.
  • The review of the increment, where the team reigns unconditionally! We also share and discuss the feedback about the increment with stakeholders.
  • An update about the internal team’s initiatives, most likely coming from the Scrum Master or Agile Coach.
  • An update on the team’s life: planned holidays, meetings, get-togethers, etc.
  • Closing the meeting with a quick review of the list of new action items and takeaways.

Guestlist: quality over quantity

While we believe in open reviews, we try to keep the guest list short but full of active and committed people. You obviously must not skip inviting the client, Product Owner, and development team. An Agile Coach or Scrum Master are always welcome, too. It pays to invite more distant stakeholders – teams or representatives of teams that collaborate on the same product roadmap, or ones that might have some touchpoints with your product. Think about other POs, architects, the CPO, etc.

Less frequently, inviting sales representatives or customer support experts might have great value, as they work closest to your users. Take advantage of the access you have to experts. From time to time, and with the client’s consent, you can invite specialists who can offer specific guidance, e.g. about optimising SEO, A/B testing, security or scalability.

Communication: engage the few, inform the crowd

There is likely a large group of people that would like to read a summary of your review, and a smaller team you would like to have present at the meeting. It’s essential to keep both groups involved and satisfied and to tailor your communication accordingly.

Find an effective way to invite your stakeholders. Sending an invitation to everyone’s calendars is a must, but maybe you can mark some guests as optional to help them prioritise? Be considerate, and make sure that your guests get (and can provide) enough value when they attend. Topics change, and so should your guests. Even if you invited 20 people for a recurring meeting, choose the few that would find the next review the most relevant to their work, and send them an email with a short agenda. Make sure you explain why their presence would be especially useful this time.

After the meeting, it’s a great habit to have the Product Owner send an email summary of the review, including the discussion topics, presented increments, feedback, etc. The summary should be directed towards every interested person, spreading the news around product teams, marketing, sales, etc. Building a subscription list for your product is a great way to make sure you leave no one behind, but don’t just spam everyone left, right, and centre.

Methods and tools: show, don’t tell

One of the goals of the review is to allow stakeholders to understand the new increment better. There is no better way of ensuring a shared understanding than by showing the real product. A verbal update is nice, but it requires the receiver to imagine what the sender means, and in the process of a review, we have no room for misunderstandings.

Some tools might come in handy, especially for a remote team. Google Meet allows a user to have their camera on and share a selected window with a demonstration at the same time. Your iOS team might like using QuickTime Player, while Android teams often prefer Scrcpy or Vysor to stream their phone screen to their audience.

Backend teams are happy to show working endpoints via Postman or Swagger. Even if this does not look especially pretty, it gets the message across and shows that there is working software you can build on. If a situation calls for it, and your audience is tech-savvy enough, present with terminal commands.

To make sure the message is clear and set in the right context, you can use some simple tools to show a process, dependencies, or reasoning. Black text and basic diagrams on white Google slides might not be the prettiest, but are definitely cost-efficient. Alternatively, consider screen-sharing bullet points in your GitHub notes.

When choosing your toolset, try to balance clarity, visual attractiveness, and ease of use. Remember that the tool should serve your goals and remove confusion, not add to it.

Four things to watch out for when facilitating a review

Even though the review is a relaxed meeting most of the time, not paying attention to some details might make it a useless and disappointing time drain.

Time and space: plenty of both

The review requires quite a lot of time and as few distractions as possible. You have to secure a room that suits everyone, encourage attendees to clear their calendars, and make sure that everyone can connect fully. For remote teams, this often means obtaining high-quality conference audio sets, maybe a set of webcams, and, most importantly, silence. Relatively quiet side-conversation in the corner is picked up by microphones and builds barriers for remote participants. Focus everyone on here and now.

When it comes to time, choose the time slot for your review wisely. For most teams, 90-minute slots are suitable. This allows everyone to present and discuss, but is not a huge burden in their calendars. Some teams will engage in more discussion, so it’s not uncommon for the review to take three or four hours. Anything more than that, however, should raise questions about efficiency.

Preparations: fail to prepare – prepare to fail

Allow the team to have a pre-meeting on the day before the review. Discuss which parts of the increment are vital, help each other come up with the best idea on the presentation method, discuss the order of the meeting, and so on. Showing your increment to teammates at rehearsal allows them to give feedback about unclear elements and transitions, and helps increase the understandability of everyone’s delivery on the big day.

Dialogue: the review is not a demo

The name “demo meeting” tends to wire our minds into having one-way communication. Demo implies that a person is presenting, and another person is receiving the presentation. But a proper review involves a two-way feedback session and a discussion. When organising a review, make time for questions and feedback. Encourage stakeholders to add their items to the agenda.

Outcome: who does what, when?

We’ve all been to meetings that seem useful and fun, but leave us with a suspicion that we’ve just wasted everyone’s time. It mostly happens when a meeting has no takeaways, action points, or notes to refer to later on. Make sure you have appointed a person that will track feedback, action items and notes.

Key takeaways

Whatever your project management framework and methods, a review at the end of an iteration is a powerful tool, if used correctly. Remember to build it around its primary goals: clarifying the increment delivered, empowering the team towards understanding business value, and planning the path ahead. Gather the right crowd, invest in preparation, and use your tools wisely to make the most of it. Send summaries of successes, challenges and updates to get people involved. Make sure to create an open environment and foster collaboration, and you will have the power of the full product team working towards a joint success.

Retrospectives: how to inspect and adapt your project

authors: Agnieszka Józefiak & Marcela Otulakowska

The Scrum Guide defines the Sprint Retrospective as an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. It’s an event that occurs after the Sprint Review and prior to the next Sprint Planning. The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements;
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The retrospective is an opportunity for an open discussion within the project team. The most important questions that should be answered, especially at the beginning of the project, are:

  • What went well during the last Sprint?
  • What should we start or stop doing?

Depending on the situation in the project, it is good to ask the team about their recent successes (highlighting even small successes may boost the team’s morale) or about what can go wrong (asking about the possible threats without using the word “threat”).

In more advanced teams, it is a good practice to conduct a retrospective focused on only one area, one that the team identifies as the most important for the project at the time, such as team velocity, communication, project risks, etc. Depending on the chosen topic, we use different tools and tailor them to the needs of the meeting.

Why Sprint retrospectives are important

The purpose of the Sprint retrospective is to:

  • Inspect and adapt – get curious and discuss what happened during the Sprint.
  • Look back at how, not at what – how the team collaborated, not what they’ve produced.
  • Do even better next time – identify the areas of improvement that the team should work on during the next Sprint.

Sprint retrospectives strengthen all five Scrum values, which are: commitment, courage, focus, openness, and respect. Once those values are incorporated within the Scrum team, it means that the team follows the Scrum pillars of transparency, inspection, and adaptation. Even if the above values are strongly represented in the team’s work, there is always room for improvement.

The retrospective makes a significant positive impact on building trust and respect within the team. To achieve it, try to build a safe environment for your team, creating an atmosphere where everyone can openly share their thoughts. Assuming good intentions and encouraging others to do so is important as well.

The retrospective can be treated as a feedback session on the Scrum team’s work. Constructive feedback on the last iteration will let the team build valuable action points that can lead to growth. Failure could be a hot topic for your retrospective. Talking about what went wrong teaches self reflection. Prepare for talking about it and support your team when facing failure. Emphasise that failure is a great opportunity for improvement.

Frequency of iteration retrospectives

According to the Scrum Guide, the Sprint retrospective should occur after the Sprint review, and prior to the next Sprint planning. It should take up to 3 hours for one-month-long Sprints, and proportionally less for shorter Sprints.

In practice, teams tend to treat the retrospective as the least important meeting, and reschedule it when there is no time. It is your job as a Project Manager to get the value from this meeting, and to show the team that it brings benefits. That does not mean that we should run the retrospective no matter what. If you have a critical bug in production, and the whole project is on fire, it would be best to wait until the situation has been brought under control, and to focus the next retrospective on this very situation. Even then, it’s better to make it shorter than usual. If you get one action point that could improve the situation, the retro can be considered as successful and valuable

It is a good practice to conduct retrospectives in projects that do not follow the Scrum framework. Every project and every team can benefit from inspecting and adapting itself.

Who can join the Sprint Retrospective?

According to the Scrum Guide, the attendees of a Sprint Retrospective are the Scrum team members (development team, Scrum Master, Product Owner). It’s usually best to run retrospectives with all team members present (clients are also team members!), but some delicate situations are better discussed in smaller groups. If you’re facing a difficult issue, you can try doing an internal retrospective and present its results to the client in a diplomatic way.

On occasion, you can invite people from outside the project to join you. If developers that are not a part of your project helped you through a crisis, invite them! They may have good insights that will help you while planning improvements for the future.

The personal retrospective can be a valuable practice to do on your own, especially after the end of a project, after achieving a milestone, or after a crisis. You can self-reflect, write down all your thoughts and analyse them. If needed, ask your leader or mentor to help you analyse the situation that you faced and learn from it.

Where to do a Sprint Retrospective?

When you are working with an on-site team, your imagination is the only limit on what the retrospective will look like. You can do it in the office, at the park, or in the cafeteria. There is only one condition: make sure that the team will feel safe and comfortable talking about delicate matters in the proposed space. Just ask them about it. The tools that you can use are also limitless (more on this in the “Tools” section).

The situation gets more complicated when you’re working with a remote team. You can also use your imagination, but obviously within certain limits. The one condition stays the same: choose a safe space for your team. The retrospective will benefit from a calm environment where nothing is distracting and where you can talk freely. Try to have clear rules for all team members about the space for a retrospective. Otherwise, they might be disappointed when the retro won’t bring much value to them.

The retrospective process and its phases

Phase I: Before the Sprint Retrospective event During the whole Sprint, observe and make notes. Observe yourself, your impressions, pay attention to how your actions influence the team. Draw first conclusions. But if something bothers you, and you feel like it may cause problems for the project, don't wait until the retrospective. Take immediate action.

A day before the meeting, review your conclusions and think of the most urgent point for your team to discuss during the event. Doing this ahead of time will give you a chance to re-think the situation in the project. Remember, when the mind sleeps, it’s still working – you may wake up with new ideas, solutions, etc. Don’t miss this chance.

Some things you could pay special attention to include the following.

  • How well the work flows (cooperation, communication, etc.)
  • Breakdowns in communication, coordination, attendance, attention, and collaboration.
  • The moments of brilliance.
  • The team’s level of anxiety and its fluctuations throughout the Sprint.
  • The team’s level of excitement.

Also, a day before the meeting, ask the team to prepare for the retrospective. Inspire them and share some tips on how to prepare. You can discuss the topic of the meeting together. Maybe they have noticed some other urgent topics that need to be addressed. Make sure that the team remembers to know that they can openly share their thoughts. No blame game!

Collectively decide on the topic. Is it going to be a specific case or issue, or a general discussion about the last iteration? Finally, choose the right method for the team (on-site, remote, internal, external) and the chosen topic.

Phase II: during the retrospective

Remind the team what the purpose of the retrospective is. Check the action points from previous retrospectives. Which ones have you achieved? For those you haven’t – why not? A retro with unfinished action points means a huge drop in involvement and heightened levels of frustration. All unfinished points should be addressed.

If the team has more serious or long-term problems with completing action points, it may be a good time to discuss this situation. Perhaps the action points haven’t been as important as you first thought. Maybe the team has been engaged in ongoing project work and didn’t have time for the action points. If that’s the case, discuss why and what needs to be done. Maybe it’s time to re-prioritise the action points and instead of choosing three per Sprint, focus on only one.

What questions to ask during the retrospective?

There are numerous questions that can be used during the retrospective. You can use existing scenarios if they fit your needs. If the retrospective is focused around a specific topic – such as team velocity, communication, or the quality of their work – introduce it to the team before asking them to answer any questions.

Give the team around 15-20 minutes to answer your questions. Remember to answer them yourself as well! Here are some example issues to discuss:

  • Start doing
  • Stop doing
  • Continue doing
  • What did you like?
  • What was lacking?
  • What did you learn?
  • What do you long for going forward?
  • What do we want more of?
  • What can go wrong?
  • Where did we succeed?

Refine your notes. Together with the team, sort the notes into main categories. Challenge the team members by asking questions like:

  • Why do we have this problem?
  • Maybe problem X is correlated with Y, not with Z – what do you think?

Vote. After refining your ideas, ask the team to vote on the most important item or items. According to Mike Cohn’s guide for running Sprint retrospectives, the ScrumMaster can have each team member vote for the one, most important idea or can use any typical multi-voting approach. For example, give each team member three votes to allocate as they wish (including all three votes to the same items).

Create action points that will address the main items you’ve just decided on. Make sure that the action points are SMART (Specific, Measurable, Attainable, Relevant and Timely). Collectively assign owners responsible for implementing each action point. You or any other team member should make a clear list of the action items. Make sure that they are transparent and understandable for everyone. Ask the owner of each action point about how you can support them.

Phase III: after the retrospective

Track the action points at regular intervals, e.g. two times a week or during the daily Scrum. To make this “moment” more visible to the team:

  • Try to add a two-minute “action points review” to the daily Scrum agenda (ensuring that the team is not distracted from the Sprint goal),
  • Name the Monday and Wednesday Daily Scrums Action Monday and Action Wednesday,
  • Try adding the action items to your Sprint board.

Challenge the team to create ideas for implementing action points. Ask specific team members for support. (“Hey Adam, is there any way in which you could support Tom?”) Look for situations that allow you to remind the team of the agreements they made. To make the implementation of action points smoother, you can teach the team how to find the root cause of a problem, e.g. by using an Ishikava diagram.

Coach and direct the team by asking additional questions, such as:

  • What exactly does it mean?
  • What exactly should be done?
  • Why?
  • When?
  • Are there impediments?
  • Are there risks and a mitigation plan?
  • Who can support you?
  • What should I know/what information am I missing?
  • Where can I find this information?
  • What are the phases of achieving this goal?
  • How can we divide this goal into subtasks?


On-site teams can use whiteboards and sticky notes. Running a remote retrospective may be more of a challenge, but there are multiple tools and apps that can help you:

  • The Web Whiteboard or the AWW App can be used for a remote drawing session.
  • Sailboat or Mountain Hiking offer retrospective scenarios.
  • Funretro is an app designed specifically for remote retrospectives. It is very intuitive and easy to use.
  • Team O’Clock is also designed to help remote teams, but it offers more features than Funretro. You can use it for planning poker and stand-ups as well. The app has several retrospective scenarios built in and allows you to create custom ones.

Retrospective rules of thumb

  • Be brave, experiment, and collect feedback.
  • Remember that the retrospective is a goal- and action-oriented meeting
  • Ask individual team members to host the meeting, then help them prepare for it. As explained by Atlassian in their guide to retrospectives, “sharing the facilitation around the team will keep your retrospectives fresh, encourage greater participation, and uncover more inconvenient truths.”
  • Use different retrospective methods. Don’t let yourself and the team get bored.
  • Track the time of each part of a retrospective. You can ask a team member to do it.
  • Stay focused on the discussion and treat the meeting as a great opportunity for learning something new.
  • Bring in outside perspectives. If you struggle with the topic, can’t choose the right tool, or need advice on any area of the retrospective topic, reach out to your leader, mentor, Agile coach, or anyone else who can help.
  • Try to follow the flow of Scrum meetings and avoid skipping retrospectives. If you or any of your team members have doubts about the value of this meeting, ask someone from outside the team for advice.

Retrospective anti-patterns to watch out for

  • Discussions dominated by one or two people. Solution: before the next retrospective, speak with the dominating person(s), and explain to them what kind of impact such behaviour has on the rest of the team. Work together on a solution that can be applied during the next retrospective.
  • Ideas not leading to improvements. Solution: ensure that your goals are SMART. You can run a retrospective on retrospectives. Maybe you’ll find out what is blocking you from achieving results. Finally, ensure that you track your goals and that the team has the capacity to achieve them.
  • Teams seeing the retrospective as a waste of time. Solution: make sure that you adjust the retrospective to the team’s needs. Try out different scenarios and ensure that the meeting is scheduled in a way that does not interfere with the team’s workflow.
  • Unstructured meetings.
  • Too many action points assigned to the Scrum Master/Project Manager.
  • Lack of the Scrum Master/Project Manager’s participation.

Who can help you run a better Retrospective

Other Project Managers at your company can help if you share your thoughts and doubts regarding your retrospectives. Ask your colleagues for advice, lessons learned, and tips. Seeking advice from someone more experienced, such as your leader, manager or mentor, usually brings many benefits. You can also build guidelines for good and bad retrospective practices together with other PMs/SMs.

Types of project handovers

author: Zuzanna Wiler

In a perfect reality, there would be no handovers and the same person would acquire the client, sign the contract, and remain present until the project’s end. None of the team members would ever go on holidays or rotate out of the project. But we live in the real world and handovers do happen. The only thing we can do is to tackle them, keeping in mind good practices and avoiding known risks.

During the course of a project, there are several important points when a handover is necessary. A usual project flow will naturally include moments where appropriate knowledge and responsibility transfer are crucial.

At the beginning of the project

Every project needs a pre-sales phase. During the negotiations, a person responsible for closing the deal agrees with the client on the scope of the project, budget, timeline, team size, etc. A document with estimations, recommendations, and assumptions should be created.

This is the moment of the first project handover from the sales team. It is crucial for a project’s success to share all relevant information before the kick-off. Full transparency, sharing all exchanged emails, talking with people involved in the first phase are necessary. Knowledge gathered during handover will prove to be relevant in case any misunderstandings crop up later on.

After the project starts, and especially when the designs are ready, the project team should look at the estimates and verify if they are still valid. What usually happens is that the amount of knowledge we have grows every day. What was unknown or assumed before the project began is clarified. This can significantly affect the original estimate, timeline, budget, and scope. It is your job as a PM to double-check what was passed on to the project team.

During the course of the project

Once we are up-and-running, there are several moments when a handover becomes necessary. The most obvious and frequent reason are holidays! A joyous time for one can increase the workload for another. Keep the handover simple and smart to avoid overburdening the person taking over. Make sure you pass on all the relevant tasks to your replacement.

It’s a good idea to work out a checklist of all the key information that needs to be passed on, such as important contact information, milestones during the absence, accesses and permissions granted, things to keep an eye on, etc. In the case of a short absence, the amount of information exchanged during a handover should be relevant to the amount of attention needed. If you are handing over a self-organising and mature team with a very capable client, just the basic information is fine. If the team is not yet well organised and needs attention from a Project Manager, even a one-hour-long handover call and a five-page handover document might not be enough. Find the right balance between giving all the necessary information and being fully transparent. You can also have internal owners of some processes to make a handover easier.

If a designer, developer, or QA expert is leaving for some time, the first question to ask is: can we still work efficiently and deliver value without such a role in the project for this amount of time? If the answer is yes, then all is good and you do not have to worry. In case you really do need a replacement, you should always keep in mind that a couple of days of overlap are necessary for handover between those two team members. Without that, the new person might be inefficient and the whole purpose of adding them to the team is lost. To minimise this risk, maximise the amount of knowledge exchanged. Remember, nobody likes to be disturbed on their days off, so make sure the handover is conducted properly and requires no follow-ups.

Another reason for a handover is someone leaving the project. There can be a lot of relevant history, particularly with bigger teams. You can prepare a manual for your successor, then organise a couple of hour-long calls to narrate the whole story and give much needed context, discuss any arising doubts, and answer questions. If possible, continue providing your assistance after the official handover, but don’t fall into the trap of being always on call. Provide both with some necessary support and a clean-cut ending so that the new person can take full responsibility for the project.

Sometimes, a person changes their role within a team. Maybe one of the developers becomes a tech lead and now has a different set of responsibilities. The handover of their previous tasks is still necessary. Support in the initial phase and a clean-cut ending should be enough to provide a stable work environment to both the person handing over and the one taking on their old responsibilities.

The situation is particularly difficult when the person handing over the project is leaving the company and you can no longer contact them. In that case, the handover has to be really well thought out and detailed, because there will be no way to fill in any gaps. It is always better to start the knowledge transfer process sooner rather than later. Make sure you double check on the person’s last day at the company that everything is covered and very precise about the progress of each task.

At the end of the project

Once the project is completed and the project team is getting offboarded, it’s important to correctly pass on the project to the client. Many companies create processes for checking if all permissions have been transferred, if the remaining (in case there are any) tasks from JIRA are exported and delivered to the client, if the project documentation is updated and includes all the necessary information, and so on. Do not leave this until the last moment. Project documentation should be updated regularly during the course of the project.