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  


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.