6 December 2020Comments are off for this post.

Definition of Ready – the Path and the Goal

Have you ever witnessed a situation where despite the team’s best efforts, diligence and meeting quality goals (Definition of Done) the customer is disappointed with the results of your work?

If yes, it is very likely that the refinement process doesn’t work as well as it should, and you should have a closer look at your entry criteria before starting work. The very fine example of such criteria is Definition of Ready (DoR).

So what exactly is DoR? In some simple words, it should help us to get to the point where a unit of work (User Story or any other Product Backlog Item) is “mature” enough so the implementation of the requirements can begin and the need behind it can be successfully satisfied. Fulfilling provisions of DoR gives you the green light to start the work - the Unit of Work becomes actionable.

And you may ask why does anybody need this DoR?

Why do you need Definition of Ready?

Imagine your team gets a task and they are to start working on it right away. How many times will they stop in order to get more info regarding the requirements, specify things, get the feedback on the way they perceive what needs to be done? Or on the other hand, how often would a customer, PO (Product Owner) or other stakeholders come over, changing their mind?

That all leads to the terrible waste of time. The team, instead of working, needs to block/put on hold their work to resolve the issues. All this should be done before the task finds itself on the team's board. If not, a lot of time will be lost to search for the answers, context switching, etc.

As you can see, this extends the whole delivery process, its costs and decreases the predictability of delivery, which is especially valued by the business.

Refinement and Definition of Ready

Refinement is a process that leads to fulfillment of the Definition of Ready. Steps in the refinement should correspond to the points in the DoR, so you can treat it as a checklist.

So what steps should actually be taken to have a valuable refinement process and a good Definition of Ready? Here at Setapp we very often refer to the following things:

1. Breaking down the requirements

Breaking down the requirements into smaller Units of Work (User Stories, tasks). Smaller, in this case, means more predictable. Less unknown, easier to estimate. Very likely to deliver within one iteration/Sprint/cadence.

2. Creating acceptance criteria

Working on understanding what needs to be done in order to satisfy the needs behind the requirements. On one hand you can say this is a “Spice Girls moment” (“Tell me what you want, what you really, really want!”), so the PO / Customer can express and specify what is needed. On the other hand developers can receive feedback on their understanding of what they think should be delivered.

In order to increase chances of success, mutual understanding is needed. The best way to achieve it is to allow both sides to meet in person. May I just quote Agile Manifesto here:

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

3. Look for impediments

Look for potential impediments, like dependencies or other blockers. If you find any, go and talk to the people, who can handle them. It makes no sense to begin with your work until they are not ready with theirs. Or at least receive (more or less) a confirmed deadline, so you would know how to arrange your own plans.

It would be good to follow up, to check if everything goes well. You may visit other team’s Daily meetings or catch them during coffee break. Hey! Do whatever works.

I believe it is a bit underestimated to recognise impediments at an early stage, and the moment you find it, go and talk to the right people. You will have this conversation one way or another, but the earlier it takes place, the less stress and pressure it would take.

There is a very interesting video from Jim Benson (creator of the Personal Kanban) about problems with the meetings we have at work and how to fix them. There is also part regarding dealing with issues mentioned above.

4. Estimates

It is always good to know how much effort is needed to implement a solution. And how long would it take to deliver it. There are tons of articles about estimating, so I will not go into details. You can use Story Points, T-Shirt sizes, etc.

Estimating can also help you with forecasting the delivery date. Based on the team's velocity you can say when the work would be finished. You may also take a more Kanban metrics based approach with Service Level Expectation (based on histogram including cycle / lead times) and/or Throughput.

There is one more reason why this part of the Refinement should be considered as valuable - it encourages discussion. This may lead to discovering potential impediments and finding out who can perform the tasks better and who may require more support.

More Lean and Kanban concepts

There are some Lean and Kanban concepts worth mentioning in regard to Definition of Ready.

Point of Commitment

This is a concept I heard about during KMP classes from Kanban University. It should support the creation of the acceptance criteria. You can say it is some form of a handshake between the business side and the team, where both sides commit.

The business side commits that this is what we really need (and sometimes it happens that there is a difference between what you want and what you actually need). They thought about it, considered it and they understood what would be delivered. The business side commits that they would not come the next day and say: “sorry guys, we need to change this all over again”.

On the other hand, the team commits to deliver the solution, with agreed quality, that fulfills the needs that the business side had stated, with forecasted delivery date, if necessary.

Where should this Point of Commitment be located? Definitely before the “to do” status on your board, before the Unit of Work is considered actionable.

Defer Commitment

This is the Lean Software Development rule number 4, created by Mary and Tom Poppendieck. I highly recommend to go deeper into all 7 rules described in their book “Implementing Lean Software Development”.

Defer Commitment means you should make irreversible decisions in the last safe, responsible moment. You may, of course, ask why?

First of all, we should not forget that software development takes place in an empirical process control environment. The Scrum Guide says:

“Empiricism asserts that knowledge comes from experience and making decisions based on what is observed”

The more we work on something, the more we learn and know about it. If we start our work too early, we may not have enough knowledge to deliver the highest value.

Another reason to wait till the last possible safe and responsible moment is Lean thinking. Let’s quote Scrum Guide 2020 one more time:

Lean thinking reduces waste and focuses on the essentials”

The situation may change, and the requirements with it. So if we start the work too early, and some factors change, we may have to do the same work twice. And that would be a waste.

You can consider Sprint Planning as a good example of Defer Commitment, the last safe and responsible moment to make important decisions.

Summing it up

One last thought. Last but not least. Definition of Ready is very useful, provides and makes us pay attention to some sort of entry criteria before starting work. We should perceive DoR as a checklist, but certainly not as an ultimate one. It should not become an excuse not to start the work, when the circumstances are dire and there is an urgent need for action.

I hope that this article gives you something beneficial to think about. If you have any remarks, please share them in the comments below. Thank you for reading!

19 July 2018Comments are off for this post.

How to prepare valuable user stories for your development team

There are many great moments in the life of a Product Owner, such as receiving thanks from stakeholders or the successful deployment of a new product, but this only comes from everyday hard work. And when I think about a Product Owner’s daily duties I always refer to The Scrum Guide for reference.

The Product Owner is the sole person responsible for managing the Product Backlog. - The Scrum Guide

The operative word of this quote is managing, in which there are many activities and one of them is to create proper descriptions of the tasks for developers. These tasks are often referred to as user stories or just stories. There is no doubt that this is a very important activity which is often postponed or neglected because it is considered boring or not creative.

What I agree with is that this is not rocket science, but I don’t agree that creating good user stories is not a demanding task. There are a couple of techniques which if correctly implemented, can dramatically improve backlog quality.

Start your work with 3C

This is also known as Card-Conversation-Confirmation flow. It is very useful when you are aiming to create a user story from only a concept.

  • Card
    This refers to yellow post-its that Agile folks usually put on walls. What this really means is that you should start with a very generic title and make it visible for others.
  • Conversation
    After sticking the post-it to the wall it will probably engage other people. They should speak freely what they think stands behind the title. Open discussion facilitates good ideas and helps everyone understand what the topic is actually about.
  • Confirmation
    Prepare the first version of your notes and groom it with your group. Eventually, you will end up with a formal story description, that is clear to everyone involved.

INVEST in good user stories

It often appears that things that are clear to business people, are not clear at all for Development Teams. The Product Owner is the one that is “Clearly expressing Product Backlog items” (Scrum Guide again). He should be more than interested in creating stories that are clear for Developers.

'INVEST' is an acronym which describes the properties of a good user story:

  • Independent
    The story should be as independent from others as possible. First and foremost it’s Acceptance Criteria (conditions that a software product must satisfy to be accepted) can’t rely on any external factors or any other stories. If possible, every story should be independent in order, meaning that you shouldn’t have to wait for starting it before finishing another.
  • Negotiable
    The story should be an open invitation to collaborate. The description and requirements in the story should not be closed for negotiations. The Scrum Team should collaborate to deliver the highest value and not to fulfill perfectly described Acceptance Criteria.
  • Valuable
    If the story is not delivering any value - then it should be deleted. There is no compromise here. However, it doesn’t always have to be direct value for your customer. As higher maintainability or reducing risks are also values.
  • Estimable
    As a Product Owner, you are highly interested in maximizing ROI. This can only be done if you actually know how big it is so you can prioritize it correctly. It also helps everyone with better planning of their work.
  • Small
    Here comes the tricky bit. I’ve seen a lot of very big user stories that take weeks to develop, but in my opinion in order to stay agile, splitting them into smaller parts is a must. We should focus on creating the smallest increments as possible, so an ideal solution for big tasks is to extract the bare minimum, implement, and evaluate the results.
  • Testable
    At the end of the day, the whole Scrum Team needs to agree that the story was actually done. To do so, we need to somehow test it. If something is not testable, then we are unable to distinguish done from not done.

Set SMART goals

Good user stories are built upon precise goals, so defining accurate goals will help with creating clear user stories. You have probably guessed already that SMART is an acronym. This one, however, has many different explanations, and each of them stands for a slightly different set of values.

The following explanations are the ones I have found to be the most fitting:

  • Specific
    The task should fulfill something. There has to be a specific goal to achieve, it cannot be generic or described imprecisely.
  • Measurable
    You should be able to measure if you have already met a goal or not. “Site needs to be faster” is not measurable. But “Site will load quicker by 10% than today” is measurable.
  • Assignable
    This doesn’t mean we need to assign a Developer right away, but eventually, we need to know to whom we address this task.
  • Relevant
    You need to stop for a moment and decide here if this goal is really giving you value.
  • Time-boxed
    Specify when you need the goal to be achieved. All goals should be time relevant.


If I would have to point out the biggest issue I have noticed in many stories, it’s the lack of business values. You can have the best description, but if you lack real value in a story, then it is pretty useless.

I have also heard that a good user story is one that is following a template: “as an Elephant, I need a trunk in order to drink". This template is useful, but I encourage you to not fix on it - don't enforce it in every single Story.

Good luck with managing The Product Backlog!

Enjoyed reading it? Then, you should read our amazing blog posts on agile product development, including: 

18 January 2018Comments are off for this post.

How to effectively use timeline to plan and monitor your sprint

The Scrum Guide™ states that the outcome of a sprint planning event should be a list of Product Backlog Items (PBIs) and a plan on how to deliver them. Similar to other things in the Scrum framework, a concrete definition of what the plan should look like is not provided. Authors of the Scrum framework give you the freedom to choose what works best for you.

So, I’ll show you a simple technique that we use at Setapp for this purpose. We call it the sprint timeline.

How does the timeline work?

The timeline is a physical artifact that should be located in a place where all team members can interact with it. Below you can see an example of a sprint timeline for an imaginary mobile application with a web back-end:

timeline scrum setapp

The rows denote the members of the development team and the columns denote the days of the sprint. The cards are development tasks. The red “X” cards are the days where team members are not available for development work.

First, you place the task card on the day that you plan the task to be done (as in Definition of Done). When the task is not finished on the planned day, then you need to move the card to the right and place a red exclamation mark on it. This shows that the task is problematic and should be investigated. You can see that 'offer list view' is causing problems and Ben probably needs some help with it. For tasks that are finished, place a green checkmark on respective cards.

Below you can see how a sprint timeline looks in one of the projects at Setapp:

timeline sprint planning setapp

This timeline tracks the work of a six-person development team and four people that are not in the development team but whose work has to be coordinated with the team. Instead of team member names, we use funny images that relate to people’s nicknames.

A timeline is an excellent Information Radiator that gives anyone that passes it an opportunity to get valuable insight into the sprint progress.

Btw, we are looking for a Scrum Master. If you are up for the challenge then send your application now!

Augment the vicinity of the timeline

You can also augment the vicinity of the timeline with additional information like:

  • A printed sprint goal to help team members stay focused
  • A list of actions from the previous sprint retrospective to remind team members 
  • Topics for next the sprint retrospective to make sure that they are not forgotten
  • Funny images and team memes to keep the spirits high

Planning the sprint

A timeline is an invaluable tool for sprint planning. We start sprint planning with a potential list of stories to be done in the next sprint that are valuable to the Product Owner (PO) and then form some coherent goal. The stories are usually estimated beforehand (most likely with planning poker) so that the PO can start with a rough list that should be doable in the next sprint taking the current velocity of the development team into account. Planning then goes as follows:

  1. Developers update the sprint timeline with their planned holidays. This ensures that the capacity during the next sprint is known. They do this by placing cards with a red “X” marks the days they will be off.
  2. PBIs are split into technical sub-tasks. In this step, there’s usually a lot of discussion about technical details of possible solutions. Some PBIs are re-estimated because team members have discovered some previously unknown details.
  3. Technical sub-tasks are printed and placed on the timeline on days that team members plan to have them done. In this stage team members may discover, that there’s too much work and some PBIs won’t fit in the sprint

The final list of PBIs and the timeline filled with sub-tasks constitute the sprint plan. Off to work now.

Monitoring the sprint

Every day, during the daily Scrum meeting developers, gather near the timeline and update it if necessary. Developers may have discovered additional work to be done that needs to be added to the plan or some work may have turned out to be unnecessary.

When a task wasn’t finished as planned it is an early warning sign that the forecasted list of PBIs may not be done in this sprint. At this point, the development team should probably talk to the PO and maybe change the planned work in a way that will fit into the sprint without compromising the sprint goal. Some stories may also require reestimation.

updating scrum timeline setapp

Team member is updating the timeline

Things to watch out for when using a sprint timeline

A timeline is a great tool. However, we have seen some negative patterns when using it in our projects which adversely affect our work. I've listed them below with the possible solutions:

    1. The timeline is not updated when the plan changes
      Sometimes team members forget to make necessary changes to the plan when new information is discovered. This is very dangerous because the timeline starts to be based on falsehoods and stops showing real progress. The Scrum Master should intervene and remind people that an up-to-date sprint plan is essential for effective development. 
    2. No proper discussion when the plan falls apart
      When a task is moved to the right some developers fail to have a proper conversation about it and just brush it off. Every time this happens there should be a thorough discussion on what should be done to get the sprint back on track.
    3. Ownership of work on a person and not on the team
      The fact that tasks on the timeline are visually assigned to people can sometimes weaken the mindset of shared team ownership of the work in a sprint. The Scrum Master should be on the lookout for symptoms of such behavior. The presence at daily Scrum as a passive member can help.
    4. The work status is not updated in the issue tracking system
      When a timeline is fully implemented, developers sometimes get so used to it that they may forget to properly update the status of tasks in the tracking tool. This may be especially problematic when the PO is not co-located with the team and doesn’t have access to the timeline. Without updates in the tracking tool, the PO may be deprived of necessary information. The Scrum Master should monitor the situation and teach the development team to keep the issue tracker up to date.


A sprint timeline is a useful tool for planning and monitoring your sprint. We use it here at Setapp with great success. What technique do you use for your Sprint Planning? Let me know in the comments below and if you have more questions about the Sprint Timeline technique email me at milosz.kosobucki@setapp.pl


setapp career scum

11 December 2017Comments are off for this post.

6 mistakes you should avoid when starting a new digital project

If you have ever managed or worked within a team that's delivering a digital project then you’ve probably come across the frustration of meeting the deadline and controlling software development costs. We certainly have and there were many reasons why we encountered problems, but we learnt from our mistakes.

Why do teams struggle or fail?

There can be many reasons, such as bad communication practices within the team or an inappropriate project management methodology for the nature of that particular product or team. The possibilities are endless because every organization has different structures and processes, and each product has different requirements and levels of complexity.

So let’s leave the ambiguity aside and focus on a more concrete example.

Let’s say that you are part of a team that is developing a hospitality and network application. You have an idea of how it should look and work, and you know that to validate the concept of the app it needs to be released as soon as possible. So, what do you do?

Choose the right methodology to develop your digital product

Here at Setapp, we use Scrum. If you work in IT, you probably already know that many teams work with this framework when they want to develop sophisticated products. However, the Scrum Guide does not state the prerequisites for starting a new project or what things you need to have ready for the first iteration. The result?

Projects being kickstarted prematurely without all the necessary knowledge or resources in place. This can result in team members being overworked and demotivated, and stakeholders feeling disappointed.

Frequent mistakes in digital project development

Some mistakes are made time and again. It doesn't matter whether you're experienced in project management or a complete rookie. Here are six common mistakes we at Setapp have experienced that you should avoid when starting a new project:

1. Having no shared vision (or sense) of the project

Let’s say you understand your product entirely - you know the project’s goal, objectives, and functionalities. However, is everyone in your team aware of them? More often than not, teams know the list of requirements and functionalities they have to design or to code, but they don’t understand why.

“Why are we building this booking application? Who is going to use it and why would they need something like it?

Everyone has to understand the purpose of the project. To be able to kickstart your project on the right foot, everyone should work towards the same goal and share the same vision of the product. A team will be much more motivated in what they are building if everyone is on the same page.

2. Not understanding the details of your product

“I want to create an app that will make traveling and booking hotels easier.”

Great! But that’s not enough for you to start creating a prototype, design it, or even code it. Having just a goal or an objective is not even enough for you to fully understand your business. Market and product research is crucial if you want other people to hop on your team. If you don’t know what to expect from the product, who will?

digital project mistakes

These questions can help you gain a better picture of your product.

3. Having no clear budget or time constraints

“We have to build this hospitality application, but I don’t know how much money/time we have. It doesn’t matter! Let’s start anyway!”

Diving into a project where there’s no clear budget or time constraints will at some point have a negative influence on many aspects of your project. Even if a clear scope and vision of the product is defined, many complications will arise. Why? Here are two examples:

  • the project’s budget might burn down before you build something valuable for your target market,
  • spending a great deal of time planning something that will never see the light of the day is a waste of everyone’s time and a huge demotivator.

Maybe, money isn't a problem for you? But still, if you don't have deadlines, for example, when the first MVP should be released, the chances are you'll encounter the risk of your product not being valuable or relevant to your target market anymore.

It’s not strictly necessary to have a detailed budget and time deadline, but it would help to motivate team members and increase their productivity, but also to plan and allocate resources efficiently.

4. Having a poorly described requirement list

Another frequent mistake is not having a features/requirements list ready before the development iteration starts. By “ready” I mean that each requirement or item in the list provides the following information:

  • A description or criteria of when it is “done”
  • All relevant materials are attached to the list. Including content, graphics, designs, access to related accounts, and anything that is needed
  • It specifies the what and why, rather than the how
  • The effort to complete the feature is estimated by the team
  • It focuses on the user’s problems, instead of the software implementation.

Having a detailed and ready Product backlog is not a prerequisite, especially if you are working with Scrum where the whole purpose is to always be flexible and be able to adapt to new requirements. However, having the first-iteration(sprint) backlog ready is fundamental to proceed with the development sprint and deliver the very first part of the product.

digital project mistakes

In "Fifty Quick Ideas To Improve Your User Stories" by Gojko Adzic and David Evans, you can find some handy tips on how to write user stories like a pro!

5. Not having prototypes tested with real users (or not having prototypes at all)

So often, teams kickstart a digital project that they don't know for sure if it will work. Stakeholders are confident that their idea will be successful, and usually, they are successful at convincing other people through research and data. However, it's important to not only have business data backing your product, but also qualitative data!

One approach is to use prototypes. If you have a budget for learning then you should use it to reduce uncertainty. For example, you can use that budget to have a dedicated mini-team to build a prototype of your app to test with real users. That is an excellent approach to gather first-hand feedback. You can discover if the features and functionalities focus on user's needs and tackle the problems you want to solve.

6. Using unknown technologies

If you start a project where your development team did not choose the technology to develop the product, you can expect:

  • a slower production pace,
  • lack of motivation,
  • a lot of uncertainty and frustration.

It’s like asking someone that is fluent in English to give a speech in Spanish. That person could learn Spanish while attempting to complete the task, but he will take longer to write it, and the quality will not be the same.

digital project mistake

Keep in mind that before the team makes a final decision on the technology, they should undertake extensive and in-depth research based on the list of requirements and designs.

If you don't; you might end up giving up on features and requirements that have value for you. For instance, imagine you have designs and specifications ready for a project.Then, in the middle of the iteration, your team discovers that they can’t deliver the project as agreed by everyone. Why so? Because of limitations in the technology.


There are more bad practices that could be added to the list, but we hope that these six common mistakes can give you an idea of the actions that you should avoid or activities that you should take a closer look at when you kick-off your next software project. Also, the purpose of this article was not to give you a checklist of steps to follow when you are about to start a project, but instead to give you an idea of the things to look out for when you are about to start a new project.

I hope this was helpful and if you have any comments or ideas about other common mistakes then please write them below in the comments section.


setapp career scum

10 November 2017Comments are off for this post.

Is Planning Poker a perfect estimation technique in scrum?

Estimating the complexity of a task, the time needed to complete it and it's combined risks are an inherent part of the Scrum process. Planning Poker is considered by some Scrum teams as an ideal approach for all estimations.

It doesn’t matter to them if they have to estimate one big task with many subtasks, twenty average tasks or the whole plan for the next release (which might contain over a hundred of tasks). Planning Poker will always be an ideal solution. But is that statement really true?

This estimation method was first defined in April 2002 by James Grenning. 

How does Planning Poker work?

There are many variations of Planning Poker rules, they all have some common parts but they can differ. The following describes the stages as we see them in Setapp. 

1. Examples Stage

At the very beginning of Planning Poker, we create at least two examples. We do this by picking two tasks from the previous sprint.

The chosen tasks should be those which were finished without any major problems and which should differ radically in complexity, in order to aim for one small and one big task.

Let's say 2 Story Points (usually 2 SPs can be one day of work, right?) and 13 Story Points. If we cannot (or do not want to) estimate based on the previous sprint then the team should go through all the tasks and choose one which has the least effort and one which has the greatest effort required. Then we can start the session by estimating those two.

2. Estimating a tasks stage

We estimate one task at a time. Then we go through the description of this task, which should be the correct user story. After reading and acknowledging the description we can start estimating the task.

Every developer picks one card from his pile and puts it at the front hidden. When everyone is ready the developers show their cards. If there is no agreement then the developers should discuss the differences and repeat voting until a common agreement has been agreed. 

3. Repeat stage 2 for all tasks.

Btw, we are looking for a Scrum Master. If you are up for the challenge then send your application now!

Why are Planning Poker cards in the Fibonacci sequence?

Planning Poker cards are not exactly arranged in Fibonacci sequence but resemble something like it. The Fibonacci sequence is a sequence that starts from 1 and then each number following is made by adding the two previous numbers. For example: 1, 1, 2, 3, 5, 8, 13, 21, 34...The reason for using such sequence is the cone of uncertainty.

This means that the bigger the task the bigger the uncertainty might be. So when a developer thinks that a task should be estimated to 10 SP he should rethink this, so he either decides that uncertainty doesn't exist or gives it more points.

When we should and should not use Planning Poker?

One may say that Planning Poker is ideal for estimating many tasks and to provide very accurate estimations. Someone else may point out that discussion and elaborative arguments in bigger teams often take more than 15 minutes per task. Overall it is good not to only focus on one planning method. Some other estimation techniques you can use are Swimlanes or the Team Estimation Game.

All in all, I think that Planning Poker is a very good way of estimating tasks, but you should consider some other techniques like Swimlanes when:

  1. You are estimating a whole release with hundreds of stories.
  2. You are in a big Scrum team (6-9 developers) with many individuals

Tips and tricks

I would like to finish with some tips and tricks that you might consider as useful.

  1. If you don’t own a pack of Scrum cards then you can make your own, simply by writing down numbers on small pieces of paper.
  2. During estimation always compare the estimate of the task to other already estimated tasks. This might help you spot the inconsistency.
  3. The team should have a consensus on the estimation but that doesn't always happen. Sometimes the discussion gets stuck, no new arguments arrive and developers still don't change their estimates.
    We need some kind of backup plan for such situations - so decide up front whether you will pick the average in such situations or proceed with excluding one highest and one lowest estimate. I personally suggest using the median and cast it to the closest value we have on the cards.
  4. Have breaks. You will often see people getting tired after a couple of tasks, don’t continue estimating and take a short break.


setapp career

2 November 2017Comments are off for this post.

Four good communication practices for distributed teams

One of the biggest, and yet common, issue during a project within distributed teams is communication. If you are working with Scrum or any other Agile development methodology, you have probably realized that having conversations every day is a valuable step in the process. This is because the team’s productivity and the product’s success are partly based on it.

Communication challenges facing distributed teams

“Communication is critical for the entire team to be able to understand the common goal”, says Scrum Master Raj Kasturi, and he is entirely right. I don’t think that there has ever been a team (whether co-located or distributed) that has reached their common goal without constant and effective communication. Maybe they got where they wanted to be, but it would take much more money, resources and time.

Therefore, I spent some time researching about what other agile teams do regarding ensuring productive and efficient communication, and I also asked some team leaders here at Setapp what they considered to be the best communication practices.

I’ve listed four of them that you should take into account if you are going to start a new digital project with an outsourced development team:

1. Face-to-face communication

Face-to-face communication is considered to be the most efficient and effective method to deliver any message to and within a development team. It is even more so when you make use of whiteboards, index cards or flip charts, etc. This type of interaction should be handled virtually if distributed teams are spread across different locations. So setting up regular conference video calls (e.g. using Skype or Google Hangouts) will create space for scrum team members and product owners to come together, collaborate, and work on the common project goals.

Additionally, It's essential to physically visit the rest of the team during the vital points in the project.  These may include but are not limited to the beginning and planning phase of the project. It’s also an excellent opportunity for team members to get to know each other better. This simple step can result in building trust and relationships. Especially if off-hours social events are planned as well.

2. Real-time communication

Who wants shorter and faster conversations and clarifications? Everyone! Real-time communication helps to overcome “communication-related problems”. Such as relying on the team hierarchy or waiting until the next planned meeting to address an issue. If you add this practice to your communication strategy within your team, you will be able to respond more quickly to unexpected situations and bottlenecks.

An example of a tool that allows real-time collaboration and communication is Slack. Since it is a chatting programme, you can have different one-on-one and group conversations. Just like on any other application of this kind. You can also set automatic reminders to other members, and integrate it with your Project Management Tool (e.g. Jira or Bitbucket). Once you do this, you receive instant notifications when someone is working on or is finished with a task.

Time doctor suggests in their post some other practices and software tools which can help streamline your communication.

As long as you make sure to establish some general rules, this tool can prove invaluable. Therefore, you should define the availability of team members during the week. As well as ask all the team members to remember that they should be available when agreed and follow everything that happens in the defined communication channels.

3. Frequent calls and meetings

Do you want to keep transparency at the core of your team? Then make sure that your team members add the practice of routine calls and meetings to their communication flow. Constant and active interaction allows team members to respond fast to any obstacle during development. It also keeps everyone in the loop. Furthermore, frequent communication between stakeholders, product owner and software development team, can prevent the “us versus them” attitude in the team during the cooperation.

Daily Scrum meetings/calls are a perfect example of good practice in communication. During such meetings/calls the scrum team, the scrum master and the product owner are all involved. They provide information about the team’s progress and obstacles during a given period. Moreover, you and your dev team should identify a person (for example a scrum master) who is responsible for intervening in situations when someone in the team is not responding to emails or messages or is simply absent during work hours.

4. Shared information repository

Having a shared information repository that all team members have access to can help reinforce how team members communicate information.

For a distributed team sharing information that is visible to everyone is a fundamental practice. It ensures transparency and can enhance communication at all times. Everyone in the project should know about this information storage.Equally important is that it should be clearly defined how to access it and what the conditions to add, edit or delete any information that it's already there are.

What is more, teams should consider the need to share information in a more formal, structured, and scheduled way. This helps everyone to understand what is being communicated and actually done without the need to call someone for clarification.

Common tools which you can use to do it are for example Jira or Trello. They are perfect for sharing task-related information within your team. Another useful tool you can try when it comes to sharing project-wide information is Confluence (or any other wiki-based documentation systems that exist).

You and your team will have all kinds of information and data available at all time, and anywhere you are. Having a repository is very beneficial when/if:

  • some team members are not around at the same time,
  • you want to check the status of a particular task that your colleague is doing, or
  • you’d like to share a document with all team members.

Summing up.

I hope these four tips were a good reminder of what good and effective communication within a distributed team should be like. By just being aware of such easy and necessary communication tactics you can already be sure that you’ll be able to troubleshoot whatever challenge comes your way. At the same time having continuous improvement in every aspect of the product development.

Keep in mind that focusing on and improving communication should be your priority throughout the whole product creation process. In this way, the team can deliver the highest business value in the shortest time and reach the objectives of the project.


setapp career

15 October 2017Comments are off for this post.

Scrum release planning – How to estimate software release date?

“Planning is everything. Plans are nothing.” - Field Marshal Helmuth Graf von Moltke 

Planning is critical to the success of any project. Plans answer the key question of the rationality of the investment itself. Plans help us to know who needs to be assigned to work on a project and help to track the progress towards the goal. And without plans projects are exposed to numerous problems.

Planning is a difficult task, especially at the very beginning of a project. This leads to two opposite attitudes:

  1. An organisation decides to skip planning altogether - They do this when they realise that it’s impossible to predict everything. However, having no plan can be really crippling to a project in many different aspects. No one knows what tasks are to be done and in what order, or who is supposed to be responsible for what and what the deadline is, just to name a few. Therefore, such an attitude happens rarely, especially that it is usually mandatory to have things planned before you start.
  1. An organisation puts so much effort into planning that it takes a lot of time - It also makes the organisation convinced that the plan must be right since so much time has been spent on it. However, a detailed plan does not guarantee that it will be more accurate or useful than just rough estimates. It also requires from you a lot of attention since you have to be careful to adjust it continuously to the changing environment. Without constant improvements it may turn out that the plan is no longer up to date. What is even worse, this can happen right after a project starts.

Why do you need to plan?

The most common reason why organisations ask you for it is because they simply need plans. Organisations use them to set up marketing campaigns, schedule product release activities, provide proper internal trainings and assign the best possible resources to the project. Beyond above there are even more fundamental reasons to do estimating and planning:

  • Reducing risk
  • Reducing uncertainty
  • Supporting better decision-making
  • Establishing trust
  • Conveying information

Planning in Scrum and other agile frameworks takes place throughout the duration of the whole project. This is not a single action but a continuous process in which after each iteration the planning process is repeated. The agile planning:

  • Is focused more on the planning than the plan
  • Encourages change
  • Results in plans that can be changed easily
  • Is spread throughout the project

Planning before a project starts

At the beginning of the project it’s really hard to predict when the project will end. That’s why before the start of a project, workshops are organised with the customers. Both the developers (those assigned to the project) and the most experienced team-leaders work together to estimate the duration of the project and its complexity.

They do this after consulting the client and from their own experience. These estimates can’t be considered binding as they must be verified during sprints. Especially that the product itself will certainly change during the development process.

Planning during project life

In Scrum, every functionality is usually expressed in a form of a user story which is placed in the backlog. For the backlog to be predictable, understandable and well-timed, you must do backlog refinement. It shouldn’t take more than 10% of the sprint time and it should cover the discussion and evaluation of tasks that are likely to be done in the next sprint.

Also, go ahead with the tasks which are difficult to implement or for which the technology is either unknown or not yet selected. It is a common practice to add a spike that has a specific timebox to find the solution and answer the question of what technology to use and to determine what’s the best way to accomplish the task.

Spikes allow teams to eliminate any problems that may occur in the future and to correctly estimate user stories which are hard to estimate at the beginning.

If you follow these practices, it’ll help you predict the release date better. It is crucial to plan other activities such as marketing, promotion, tests etc. What’s more, working in Scrum enables the release date to be automatically updated after any change in the product backlog is made. This ensures the organisation stays updated.

Remember: working on the product backlog is a full time job for a good product owner, not just a single event.

How to estimate the release date?

To do this you will need to:

  1. prepare the product backlog for the first release
  2. estimate all user stories with your development team
  3. check the average speed of your development team (a common practice is to take an average from the last three sprints)
  4. divide the total number of story points in the product backlog by Avg. Dev team speed and you will get the number of sprints needed for the release.

One of the most useful tools that can help to get the release date is Jira. Continue reading if you want to know how to use it for this purpose.

JIRA version report

If the product backlog is complete and all the user stories are estimated, you may assign a version to the backlog items to get a version release report.

You can access this chart in section: reports> report version. The sample report looks like this:

JIR version report

The projected release date with some margin is available in the upper right corner of the chart. You can find more info on this subject on Atlassian’s support page.

Interesting numbers

scrum release planning and estimating

If you are concerned about the numbers presented above, remember to always focus on the planning. Spend just enough time before the project starts to plan and provide estimates. Try to reduce risks before the project starts and always keep adjusting plans.

Let us know how you estimate release date for your projects. We are always open to new ideas and suggestions.


28 September 2017Comments are off for this post.

A recipe to get to know Scrum – with Scrum simulation

This blog post was originally published in Polish on IT-Leaders.pl and is co-written by Anna Finn, Language & Communication Specialist at Setapp.

Imagine that you have bought a house and you would like to renovate it. You choose the best man for the job in town. Then, you decide on the final look of your new place. The house will be ready in just a year. However, during the works you will be unable to contact the people who renovate it.

You cannot introduce any changes to the first project or check on the progress. Moreover, you will not be able to verify if your original project is as functional as it was in your head. There will be no corrections possible as it comes to the first draft. You will have to wait patiently and keep your fingers crossed that you like the final effect. This is exactly what the waterfall model looks like.

The agile methodology in Scrum

One of the alternatives to the waterfall model is the agile approach where you deliver products iteratively and incrementally, e.g. Scrum. Scrum Team works in time intervals, called sprints. The end result of a sprint is delivering a working product.

Unlike the waterfall model, Scrum provides transparency at every stage of building the product. Thanks to this you can actively participate in the creation process. You can decide if the achieved effect is satisfying, if you are heading in the right direction and you can react quickly in case you need to introduce any changes or modifications.

More and more teams choose to work with Scrum when they familiarise themselves with its basic principles - in theory, they are easy to understand. Unfortunately, if you think it is so simple, your initial euphoria can quickly disappear when you realise that Scrum, in fact, is difficult to master.

Lukasz Setapp

However, when the methodology starts running in your bloodstream, everything is much easier and you start wondering how it is possible to create new products without Scrum.

Introducing scrum principles with LEGO

If you would like to introduce your team to Scrum principles or if you are already using it but you would like to refresh the knowledge, an amazing way to do it is Scrum simulation with LEGO. Sounds childish? Nothing of that sort. This training enables you to understand Scrum better using a very simple tool - LEGO blocks. It shows how sprints work, lets you evaluate the team’s work and allows you to see the areas that still require working on.

What are the requirements?

  1. You will need two hours to conduct this training if you want to use planning poker or a similar technique. (If you decide to use fast estimation, an hour and a half should be enough).
  2. The ideal size of a group that takes part in the exercise is two to three teams consisting of four to six people.
  3. LEGO box per team - “Basic Brick Set #61772” will do the job.
  4. Apart from the bricks you need to make sure to provide enough space for the teams to present their final products along with the training essentials - i.e. flipchart, markers, post-it notes and the planning poker cards if using.

The training starts with a backlog which you need to prepare beforehand. It should be open and what is crucial it should not contain any precise instructions what you should do step by step. The vision is more important than the detailed directions.

The rules of LEGO simulation

  • The first step of the training is the preparation stage (pre-game). It is followed by the game stage itself (game) and then you go to the final summary (post-game). All three stages are of equal importance so you shouldn't skip any of them. The objective is to build a city with LEGO bricks. 
  • The city is constructed during three sprints in the main stage of this simulation. However, the number of sprints can be changed to even five or seven. During the preparation phase, you create the teams and the visions of the city. You define the processes and estimate in order to move to sprints and the game itself.
  • Each sprint is divided into three parts: three-minute planning, seven-minute execution and five-minute review. During each sprint you have time to see if the project is heading in the right direction. You can also introduce changes if needed. Once you finish all the sprints, you should always have time to sum up the whole training.

Takeaways from LEGO simulation

  • The LEGO simulation shows exactly who takes which roles. You can observe who is more of a dictator than a team player, who is more outgoing and loud and who prefers to stay quiet. It will also be a fantastic opportunity to see what mistakes the team make.
  • Random and unpredictable elements are introduced. For example sickness of one of the best team members - which means that the person cannot participate in the game for a bit. Another can be budget changes - which is equal to getting rid of the last sprint. Such elements allow you to check how groups cope with change and re-grouping that is needed.
  • The discussion panel that should finalise the training is the time when all the participants can discuss together what they liked about the exercise and share their insights.

Even if Scrum is present in the life of your company, this LEGO simulation can be very useful. You can use it as a refresher rather than a training per se. However, if you have never worked with Scrum but you would like to give it a go and share with your team a new approach to working with projects, the described LEGO simulation can serve as the first step in that direction.

Wrapping up.

We live in times when the only certain thing is the change. Therefore, if you want to keep up with the ever-changing world around you, you need to change with it. You should choose the solutions that can help you become a better version of yourself.

Scrum guarantees you transparency in the processes. Moreover, it lets you keep an eye on them and assures the highest quality of the end product. A lot of enterprises has already succeeded in raising productivity thanks to Scrum. So, if you do not want to stay behind, you should become friends with this methodology as soon as possible.


setapp career

4 September 2017Comments are off for this post.

Story Points and understanding why two story points don’t equal one day

Sounds familiar? I’m sure you have encountered something similar at the very beginning of your journey with Scrum. You were counting Story Points for a certain number of days to check how your team performed and answered some key questions:

  1. Who performs best?
  2. How many days are needed to deliver a task?
  3. How many days are needed for the next release?

What is a Story Point (SP)?

Before I elaborate further the 2 Story Points ≠ 1 day concept (using a case study), I’d like you to get a better idea of what a Story Point is.

A Story Point is an arbitrary measure that expresses:

  • the complexity of a task,
  • effort needed,
  • uncertainty, e.g. the technology is not known yet, the time spent on discussions may vary when you have to depend on other teams.

Please remember! A story point is a relative measure and not an absolute one (like measuring in days or hours).

Let me explain this using an example.

There are two developers - one senior and one junior. When they estimate a feature with SP, they should find the same task equally big (e.g 8 SP). It doesn’t matter if it’ll be delivered by the Junior or the Senior developer. 8 SP means 8 SP!

The time needed to deliver 8 SP is estimated by taking an average of the team’s past performance (not individual developer’s).

However, if they measured a task in days or hours, the senior developer would say 2 days and Junior would say 8 days. And both of them would be correct. So what can a product owner do with such estimation?

It’s useless because since Scrum teams are self-organizing, they do not know beforehand who will be responsible for the development.

If you want to check whether a task will be delivered on time, it is always better to ask the development team, than guessing it by converting story points to number of days (even though the development team's velocity is quite constant).

For example 60 story points per 6 developers per 10 days. This does not mean that 1 developer will deliver 1 SP in 1 day. The entire development team is needed to deliver the user stories, especially when the tasks are interrelated.

story points scrum

By using Daily Scrum you can check how the team works and performs. You can also ask the team the right questions to get the information you actually need.

What a Story Point is not:

It’s not a measure equal to time, but can be used to estimate a release date,

It’s not a measure that describes the efficiency of developers,

It is not a measure to compare the performance of two different Scrum teams.

To provide estimates in Story Point development teams usually use two common methods:

I will dedicate a separate blog post to explain in detail.

What does it mean to burn story points?

Every user’s story is estimated in story points which are burnt once it is done. By done I mean that it has passed all the necessary tests, the bugs are fixed (if there were any) and the user story meets the acceptance criteria described by the Product Owner and the Definition of Done.

To present the overall sprint progress towards the sprint goal you can use a burndown chart. Below you can find an example from a sample project.

Burnout chart Story points

There are 17.5 SP to burn in this sprint (left upper corner). As you can see, the team should follow the grey line that represents the sustainable development towards the sprint goal. The end of the red line represents the current status. On that basis, you can say that team should have burnt at least 5 SP.

It could indicate that the development team is lagging behind but in this case, they are not. Here the team have been working on the User Story that contains 8 SP, so it should be delivered at the end of the following day which means that they will still meet their guideline.

This type of a chart helps teams to check if they are going according to the plan. Checking this chart on a daily basis and asking the team if the sprint goal is safe or endangered is a good practice that prevents the team from failing.

It is the Product Owner who decides if user story is done. If not - Story points are not burnt and user story should be done again correctly. This is the case that indicates that user story description, acceptance criteria or/and the Definition of Done may require improvement.

If you are tempted to check this using Jira or other project management tools, it’s not a good idea as most probably you will receive an adverse effect. It doesn’t matter if you want to find “the best” developer or motivate the “weaker” one.

It’s ‘NOT OK’ to motivate and guess if someone is weaker by looking at their burnt story points as the person in question might be the best programmer in the team while burning the fewest points.

“Story Points are not used to measure developers’ individual performance.”

Moreover, please always remember that:

A Scrum Team is self-organizing and together performs sprint tasks to maximize the synergy effect. More experienced programmers help less experienced ones in their tasks and offer their knowledge while planning tasks. This takes a lot of time. As a result, the more experienced developers often leave the tasks incomplete while burning story points.

This also happens when a tester is a member of the development team and they are not assigned to any task. He won’t burn any points but this doesn't mean that he’s inefficient as he still brings value to the team.

If you want to measure how a scrum team is performing, you should check:

  • Whether it achieves a sprint goal or not
  • If the team members constantly develop their skills
  • Delivers high-quality results, and/or
  • If its performance is predictable

To settle developers by who burns story points faster will lead to solely focusing on their individual work and will break the flow of information and knowledge between them. This is because communication takes a significant amount of time, which according to the developers could be used for pure coding.

Negative effects of solely focusing on burning story points and not working as a team.

The lack of communication leads to errors and misunderstandings. This negatively affects the quality of the final product as well as the speed of the entire team.

Another consequence of this action is that not everyone in the development team has the full knowledge of the product backlog. There could be times when, for example, someone is on vacation and no one else is able to complete the task.

The synergy effect of the development team is also reduced. The Product Owner and the team should work together on backlog grooming (refinement) and not just perform tasks "commissioned" by the Product Owner. The effect of synergy is a fundamental advantage of Scrum, so it's not worth losing it.

Let’s recap

Story Point is a measure that works well in agile teams and changing environments. For teams which have a stable velocity, Story Points are better at answering questions about the planned release date than time estimates that often reflects customer expectations rather than the real time and effort required to complete the tasks.

For Story Points to answer questions on the release date, you must take care of the product backlog by regularly refining it. This shouldn't take more than 10% of the Sprint time.

Everything in Scrum is strongly interrelated and interdependent. This framework is extremely coherent so giving up even one of Scrum practices can cause many unwanted problems in the project as a whole.

If you want to know more about Story Points, drop me a line. I'll be happy to share my knowledge with you.


Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616


Clutch award badge
Instagram Icon

©2020 Setapp. All rights reserved.