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: 

1 February 2018Comments are off for this post.

How to effectively form agile teams in your company

Many of us work in software development companies that use agile practices and frameworks. For most of us, it works well, and we’re satisfied with the results. However, most agile frameworks are not complete methodologies, and therefore don’t include solutions to all of the problems. For example, how to form new teams, how to educate clients and how to organize your work as a PO etc. In this article, I will present my view on forming agile teams within a company.

To do this, I will assume some typical scenarios. We have a company with several projects on the go, and one of our new clients is close to making a deal. In this situation, we have to fully prepare for software development - we have to form a team. There are many ways to handle this process, so let’s find the one that will best suit our needs & capabilities.

1. Ideal Scenario 

First off - the ideal situation. Imagine you have a dozen agile developers who are good at self-organisation, are technically skillful and have advanced soft skills. If you have such a group, you can simply arrange a meeting with them and the new Product Owner, who will present the product vision and high-level requirements. Together they should be able to determine the necessary details, skills, and technologies, and enable the developers to self-organize into team(s), based on many factors, including:

  • their feeling of the ideal team size (which depends on the scope, possible parallelization of tasks, required time/budget and other factors)
  • required skill-set
  • other project-dependent factors (like available budget, special requirements etc.)
    In reality, most organizations/developers are not mature enough to follow this process in every detail. So we have to aid it in some way to make it happen.

2. The real world scenario

A more real-life scenario is that a group of developers (potential future team) will meet with a client/PO, but will be accompanied by a Scrum Master and/or other experts (like team leaders, seniors, technical managers etc.). They will aid the process by facilitating the developers’ decisions, suggest solutions, or, as a last resort, make decisions if none are made by any group members.

How much of the decision-making is done by developers depends on the maturity of the agile mindset across the organization. By that, I mean how skillful the developers are themselves (technical + soft skills), how much practice they have in self-organization, the level of trust inside the company (do managers trust developers’ decisions?), and how proactive the developers are at achieving goals.

Our goal is to make decisions with all parties involved. So in the future people will be able to make decisions for themselves. If somebody is affected by a decision then give them the ability to make a decision about it! They will be the ones who have to cope with the consequences, so why should we make sub-optimal choices for them? If we don’t trust our people, perhaps we should stop and think about it for a second. That can be a very limiting factor for our company growth and scalability.

While you're here, check out our latest job offers. We are still looking for a Scrum Master.

3. Agile organisations

If an organisation has been following agile practices for a long time, then it should already have several agile teams working on products. It’s safe to assume that some of these teams will be finishing work on the product sometime soon.

Keep the development team consistent

The best practice is to try to keep the development team composition unchanged, because every change will have a temporary negative impact on the team’s efficiency, due to repetition of the process of team forming & normalizing. It’s especially prevalent if we decompose teams entirely and assemble them from scratch with every new project - efficiency will be sacrificed by a huge amount, people will have to re-learn to work together (see: The Seven Wastes of Software Development) etc.

So in practice, you should be able to frequently re-use an already existing team, maybe with some small-scale changes to their composition. An existing team will be more efficient than a new one because:

  • people already know each other,
  • they have very good communication between them,
  • they know how to collaborate and what to expect from each other (as if they are one big family).

It requires months or even years of working together to achieve this. So if you already have it - don’t destroy it and try to make good use of it.

Focus on teams, NOT individuals

Agile organisations should really focus on the team, rather than making decisions about individuals as if they were separate entities. Idealistically, all people in the organisation should be well-connected as if they were one big team (“family”). In practice, interactions in such an environment will be very complex, and because we have limited time, focus & resources, we need to structure this approach by introducing a smaller concept of a team, which consists of no more than about 10 people. This approach can be of course scaled further into a bigger organisation, but that’s a topic for another article.

4. Anti-patterns

Like with all agile processes, we should try to avoid making decisions by people who will not be involved in the final usage of the product.

A typical anti-pattern here is to make behind-the-door decisions by the CEO, sales department or technical leaders etc… What usually happens next is that a group of people (the “new team”) gathers together and they shortly discover that decisions were far from optimal. So they quickly become frustrated. This may mean reworking things or create serious doubts about whether there was any point in using the effort already put in. This results in lower performance, higher cost, and eventually in less trust in management’s decisions and competences.


To help you remember the uppermost practices, here’s a short summary:

  • Build your teams with skillful/capable people from the beginning. I can’t stress this enough - if you don’t, it will be almost impossible to make up for it later
  • Take care of your teams - don’t divide them, don’t terminate them - cultivate them and help them grow
  • Try to make your decisions as close to the source as possible. The best decisions are made by people directly involved with their outcomes
  • During the growth of the team’s organisational skills: facilitate their decisions and help them, until you’re satisfied with results that they can achieve themselves
  • If all done right, in the end, you will have autonomous teams, which don’t require micro-management. It'll give everybody the ability to focus on other areas

P.S. If you would like to learn more about software development methodologies then check out some of our other blog posts, including:

How to effectively use timeline to plan and monitor your sprint

Is Planning Poker a perfect estimation technique in scrum?


setapp career scum


25 January 2018Comments are off for this post.

Four valuable practices for a better code review

Agile is all about constant improvements. We do retrospectives, we improve our delivery pipelines, we make our work more transparent, and we also do code quality improvements.

The most famous code quality improvement practice is code review. Code review is basically a process of verifying and improving your code quality. It not only helps you make your code better but also helps to educate your teammates. Code reviews can differ in many ways. You can use different tools to share changes and comments or you can just do a face-to-face review and fix everything in real-time.

The pitfalls of code reviews

Bad code reviews can harm your team and lower software quality if you don’t apply them properly. How come? Code review is a communication tool. People are fragile, and people make mistakes. Connect the dots.

If you are too sloppy, you will end up with messy code. If you're too rigid, you will break the team unity and create a stalemate. So, how can you overcome these problems? Here are some tips.

  1. Order your code review goals
  2. Be precise and descriptive
  3. Be motivating and give a good example
  4. Automate as much as possible

1. Order your code review goals

Code review will not fix all code flaws. You need to focus on the most important things.  What is the most valuable outcome of a code review? There is no obvious answer. For instance, a team may value discovering vulnerabilities over improving code readability. If you order these goals, you can focus on important stuff. I suggest writing down all the code review goals, and order and share them across the team. A list of goals may also highlight bad practices the team should abandon or things that should be covered by using another tool other than code review.

Here is the example of an ordered code review goals list:

  • Discover architecture issues
  • Discover performance issues
  • Inspect changed APIs
  • Improve code readability
  • Teach good practices
  • Find naming mistakes
  • Discover bugs
  • Discover vulnerabilities
  • Find typos
  • Find code style issues
  • Laugh over sb else’s code
  • Spend some time on sth else other than programming

You can agree on goals in many different ways. One of them is to create a stylesheet. For instance:

style sheet code review

2. Be precise and descriptive

You find a code issue or you may write a two-word comment to fix it. You may also describe:

  • What is wrong with the code
  • How does it impact the solution
  • How to fix the problem

Which approach is better? The rule of thumb is to answer these three questions. It improves developer experience tremendously. Developer experience is very important, especially if you work in a distributed team.

You could ask how many lines of code you can review on a single day. The intention is obvious: to stay focused. But we are not creating simple procedures these days. Our code is split into functions, classes, modules, and sub-applications. You can set a lines-per-day limit. However, it might prevent you from seeing the bigger picture. I suggest checking your code review goals and decide if a lines-per-day limit makes sense to you. If you run into a code review size problem try to focus on a single goal, starting from the top of the list.

3. Be motivational and give a good example

As I said before, a code review is a communication process. You communicate possible code flaws. Your teammate communicates if he agrees with you or not. Sounds simple, right? Unfortunately, it can get really messy when emotions get in the way. There are a couple of problems.

First of all, software developers are often tied to their solutions. You know this image, right?

richard's software guide

If you try to force your approach, you might end up arguing about spaces vs tabs.  You know you're right. Your colleague knows he's right. You're both wrong. What is the outcome of such an argument? Wasted time and higher tension for sure.

The second thing is that developers try to work like compilers by finding all the mistakes and waiting until your teammate fixes them. It tends to punish minor flaws while ignoring major improvements. How is your teammate suppose to know that he should repeat the very same approach the next time?

The last issue is also connected with the compiler-like code review. If the pull request creator won't fix all the comments, then you won't approve the PR. The code review comments should make the product better. The product gets better when the team gets better. If you push your teammates too hard they will start treating your requests as too rigid and ignore them. There is no point commenting on issues then.

The productive way of doing code reviews allows step-by-step improvements. You want to experience better CRs? Start changing your behaviour first. If you follow the rules below, you will share the positive and professional attitude across your team. The rules are simple:

  • Stop treating code personal.
  • Compliment good solutions.
  • Gradually improve your coworkers' skills & knowledge.

4. Automate as much as possible

A code review requires huge amounts of attention. Fortunately, there are lots of tools that can make your life easier. Many code flaws have been discovered by code analyzers. Some of them point out code style issues, whils others discover possible vulnerabilities or performance issues. Some of them find spelling mistakes and words that are not allowed in your public API code docs.

We can recommend a couple of tools if you work on .NET/JavaScript stack:

  • StyleCop.Analyzers - a tool for C# applications that searches for code style issues
  • ESLint - a tool for JavaScript code that makes JS syntax more strict (e.g. by enforcing semicolons at the end of statements)
  • SonarQube - a continuous integration tool that searches for common code flaws (duplication, vulnerabilities etc.)
  • custom .NET Analyzer- you can write your own .NET code analyzer that works similar to StyleCop.Analyzers but is focused on your custom needs

Remember that automation is more valuable if it works on all developers' machines as well as on the CI server.


There are plenty of ways to improve your code review. However, the most important thing is to be aware of your team and product needs and craft the code review implementation adequately. Always keep in mind that code review is a communication process - the better you explain it, the more value it gives. In order to reduce the scope of conversation, automate validation of repeatable stuff that the team have already agreed on.

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

21 November 2017Comments are off for this post.

How to control software development costs? [5 practical tips for PMs]

According to research published in the Harvard Business Review, one in six IT projects has a cost overrun of 200 percent. That’s a very alarming number - mismanaged projects make huge losses for companies and often costs managers their job. So, it wouldn’t be a huge surprise if your project gets out of control. The question is how to effectively manage software development costs?

1. Budgeting instead of estimating

As Debbie Madden once wrote in her article you don’t need an estimate - you need a budget. Sometimes it’s faster and cheaper to build something than get a precise estimate of it. Estimations are simply too detailed for strategic decisions - they try to predict an unpredictable future. If you are seeking to estimate the whole project at the very beginning, you are wasting a lot of time and energy. To avoid this focus on getting a ballpark figure to plan the budget.

Here's how you can budget your project like a pro:

  • Identify the decisions you have to take and the questions you need to answer.
  • Break your project into smaller pieces when it comes to the size, complexity, and duration - it will be easier to understand and execute.
  • Take advantage of the reference class forecasting - look at similar past projects and their outcomes, it’s one of the best methods to get a ballpark figure.
  • Prioritise and identify “must haves” and “nice to haves for your project to define your minimum viable product (MVP) and make the budget more precise.

2. Start with prototyping

Simply put a prototype is just a three-dimensional version of your vision. It promotes early interactions between users, developers, designers and other stakeholders of the project. Prototyping enables you to identify and handle the biggest risks as early as possible.

There are a lot of prototyping tools available on the market so if you feel you need, then utilize once because it’ll serve you well. But remember, it’s more important to just do it, rather than how you actually do it. There are no strict rules - it’s ok to experiment and play with convention.

The benefits of prototyping:

  • Better communication: Prototyping helps you describe your vision more efficiently to the whole team involved in the product development. Thanks to which you can avoid many misconceptions at the very beginning of the project.
  • Faster iterations: Your idea works perfectly in theory until you start drafting it into something tangible by developing the prototype you are forced to answer many crucial questions early.
  • Proof of concept: Having a prototype you can achieve greater stakeholder engagement (it looks more professional and encourages others to take your project seriously). You can also prove that your idea makes sense and is worth investing time and money in.
  • Possibility to test your product early: It is the best way to engage end-users in product development from the very beginning. This is crucial if you'd like to avoid ending up with a digital project no one wants to use.

3. Conduct user tests early

A prototype is all you need to start testing your product idea with real users. It will reduce many headaches later on. Of course, it requires a different approach to testing the final product but done right is extremely beneficial. What is the most important - by incorporating user testing into your project development cycle makes you focussed on users needs, not product features.

Tips on how to start with user testing:

  • Define your goals for each stage of testing based on your prototype functionalities
  • Describe your target group - you can do this by building users personas 
  • Hire someone experienced with user testing to choose the right methods, who can build test scenarios and who can run tests and prepare a report for you
  • Implement the findings into your product development process as fast as possible and repeat the whole thing with the next features ready

4. Take care of the quality

Investment in quality assurance early on can have an excellent ROI, especially if you take into consideration the maintenance costs related to the project. It may not be exhilarating to pay attention to the quality from the very beginning, but it will pay off later increasing customer satisfaction and reducing product failure rates.

Remember that quality assurance is more than “testing”. It’s a complicated process that should involve all product development team members to be entirely satisfactory.

There are many different approaches to quality assurance depending on the nature of the project (here you can find ten best practices to deliver quality software ), but some tips are universal:

  • Choose what is the most important for you when it comes to the quality and prioritise it from the very beginning.
  • Communicate your quality goals to the team and make sure that all suppliers are also aware of them.
  • Break free from the classic roles - all team members should take care of the quality.
  • Automate testing if it’s possible - it can save tons of time and energy.
  • And finally conduct the user test early

5. Forecast regularly

It’s the best way to control the costs and respond to changes quickly. Budget is a living part of the project and only by knowing its current state and forecasting in the near future, you can manage the project and correct spending on time if needed. Product managers who carefully watch budgets during the product development lifecycle are on their way to avoiding costs overrun.

 Some points to keep in mind when forecasting your project:

  • Forecast frequently: It will help you to oversee the project stay agile and to respond to all changes quickly.
  • Forecast not only spending but also resource usage to make sure you can stay not only in the budget but also deliver the project on time.
  • Keep everyone informed: Your team, suppliers, and stakeholders should be aware of your project status to contribute to it in the best way.
  • Sometimes you can cut the scope of your project and still meet the business results


Keeping control over digital projects cost is not an easy job but done right can pay off in many ways - from business success to personal achievement. Fortunately, there are some rules you can follow to succeed. Let us know if you found it useful!

We are an agile software development company specialising in web, mobile, and VR/AR applications - if you are looking for a team to work with you on your digital project just drop me a line at filip.andrzejak@setapp.pl  


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


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.