Scrum Mate Blog

Goodbye Scrum Mate — Meet PM Engine

Tue, 22 Jul 2025 00:00:00 GMT

Goodbye Scrum Mate — Meet PM Engine

We’ve been quiet for a while — not because nothing was happening, but because we had a lot to figure out. Behind the scenes, we’ve been rethinking how to build a better long-term product for you, and how to compete in the crowded project management space.

Now, we’re ready to share where we’re headed.

New investor, same team

Earlier this year, our team received significant growth capital from a team of investors with decades of experience in building software businesses.

This partnership provides:

More financial stability and resources to grow than ever before.
The same product team is still here, doing the work.
A sharper, more focused vision for the future.

Our new investors have not only supported this evolution—they have been instrumental in shaping it.

What’s changing?

With the backing of our new partner, we took a fresh look at the project management market and set a new direction.

Scrum Mate is becoming PM Engine — a self-hosted tool for organizations that want full ownership of their project data, without giving up simplicity or usability.

PM Engine vs. Scrum Mate

PM Engine builds on Scrum Mate’s foundation. It will carry over most of its features, with a modernized UI and a more flexible, long-term architecture.

While it will feel familiar to Scrum Mate users, PM Engine is a fresh start. We’re rethinking a few features to make the tool more adaptable and customizable over time.

The first few releases will not include every Scrum Mate feature. Some, like Topics, Dividers, and Planbox, will be missing. But we’re committed to supporting the same real-world scenarios — sometimes with different implementation approaches.

When PM Engine is ready, we’ll provide a clear migration path for moving your projects over.

What happens next?

Right now, we’re deep in under-the-hood improvements and giving the UI a gentle refresh. Our goal is to make PM Engine ready to run smoothly in your environment. Our goal is to release the initial version of PM Engine in Q4, 2025.

Why self-hosted?

We see a clear market demand for simple, affordable project management tools that also offer flexibility, customization, and security. We've concluded that a self-hosted model is the best way to meet all these needs together.

With self-hosting, you get:

Full ownership and direct access to your project data
Flexible hosting (your servers or your private cloud)
Predictable costs
Freedom to decide when and how to update
Easier compliance with security standards

We’ve asked the same question you might be thinking:

“Is the extra admin effort of self-hosting worth it?”

That’s exactly why we’re building PM Engine to feel nearly as effortless as a SaaS tool. You won’t need a support team or an IT department. You’ll get a simple setup, clear instructions, and help when you need it.

In this article, we share our thoughts on why we chose the self-hosted model.

Questions you might have

We know this is a big change. Here are answers to a few questions we anticipate.

1. How long can I use Scrum Mate?

Scrum Mate will be available at least until the end of 2025.

We plan to release PM Engine and its migration tools this autumn. You’ll get plenty of notice, clear instructions, and support to make the transition smooth.

One thing we can promise: we won’t leave any existing subscribers behind. We’re here to help you work through any specific needs.

2. Will I lose any features if I switch?

Initially, you might. The first few versions of PM Engine will not include topics, dividers, or the 'Planbox' feature. We are rebuilding this functionality with care to create a stronger foundation for future improvements.

3. What will it cost? Will pricing change?

We have not finalized PM Engine’s pricing yet. However, we can make this promise: if you’re a current Scrum Mate customer, your pricing will not increase.

4. What if we don’t have an IT team to run a self-hosted app?

You won’t need one. PM Engine is designed to be lightweight and easy to manage without special infrastructure or deep technical expertise. We are also building automatic backup and restore features to ensure reliability and peace of mind.

If you prefer not to host it yourself, we can run a dedicated PM Engine instance for you. Terms and fees will be based on your specific needs.

5. How will the migration work? Will our data be safe?

You will be able to transfer all your projects and data using our migration tools. Your entire history will remain intact, and we will guide you through every step of the process.

Let’s talk

We understand this is a significant shift. We will be sharing more details soon and are always happy to hear from you.

Thank you for being on this journey with us. We’re excited to show you what’s next.

Scrum Mate update - June 2021.

Thu, 24 Jun 2021 00:00:00 GMT

Scrum Mate update - June 2021.

We’re super excited to announce a new, more modern look for Scrum Mate!

Dark mode

We’ve made several improvements, but the game-changer is the much-requested dark mode!

Go to your profile menu and click “Switch to dark mode”.

And voilà – you’re on the dark side of the Force.

Add stories in between cards on boards

You can add new cards on the board wherever you wish. Just hover over the space between two cards in a column and click “Add story”.

Checkboxes to select backlog items

You can select backlog items more easily with checkboxes.

You also have a handy counter at the top (to keep track of your selected items) and a convenient “Clear selection” option.

New “On board” section in the project view

If you have multiple team boards connected to a project, the “On board” section will show the content of each board in a separate tab.

You can quickly navigate to a connected board by clicking on the arrow icon at the top-right corner of the board tab.

New sprint bar

When your team is running a Scrum sprint, you’ll have a neat row of dates of the sprint, and you can edit and finish it right there. Plus, we’ve gone for a more intuitive sprint icon!

There are other little changes you’ll notice, but these are the ones we wanted you to be aware of before we hit you with our new look 😎 (nothing radical, don’t worry).

Painless timesheet for agile teams

Wed, 18 Nov 2020 00:00:00 GMT

Painless timesheet for agile teams

We know that timesheets are a headache for most creative agencies, so we developed an approach that helps organizations to achieve timesheet compliance while making work administration effortless for team members.

What do we mean?

Automating the process of logging your time to keep you from having to worry about yet another administrative task.

We do not think that automation should be achieved by installing tools that sneak into your operating system and monitor all your activities on your computer.

Hence, we created an automatic time tracking approach that treats team members as human beings, not robots.

Our approach is based on two main premises:

Time tracking shouldn’t be used as a weapon to exercise control over team members. It should merely serve the purpose of collecting data that helps businesses to allocate expenses across various activities and projects.
We recognize that the effort spent on creative work can’t be measured by simply tracking time spent in front of a computer, therefore it can’t be fully automated, and needs a bit of human touch.

The work log assistant

The work log assistant uses the data of the activities you perform on the team board, story cards, and tasks.

Once it gathers information about your activities, the assistant provides a handful of services for you to make work logging painless.

A reminder of your work history

This feature makes sure that you don’t miss out on or forget anything. The assistant presents a list of all the cards you opened on a day and helps you remember what you have been working on. You can access that information for the current day and up to 30 days back in time.

You can easily add work logs to any of the listed cards by manually entering the time spent on them.

Meeting work log targets

Many agencies expect team members to record a minimum amount of logged work on each workday. The work log assistant helps team members to achieve this goal by providing real-time information about their actual logged work compared to the set daily target.

Semi-automated work logging

This feature makes work logging even easier. If you update the status of the tasks you work on regularly, the assistant provides you with a great bonus: a prefilled work log calculation for the day.

Based on your interactions with the story cards (when you open one, comment, or update it), Scrum Mate will suggest the amount of time you spent on it. And, it will automatically prefill your work logs with that calculation. You can always add your human touch by adjusting the data manually to make it more precise.

Have full control over your work logs

It’s not just about recording work logs, Scrum Mate also makes it easier for you to manage them.

You can get full control over your work logs through the ‘My Work Logs’ page: find an overview of all your work log data in a calendar view, select dates, or date ranges, and review all the tasks you logged work on.

Work logs are just a fraction of Scrum Mate’s capabilities.

We strive on building handy solutions for agile organizations to manage work effectively without overcomplicating administration.

Want to know more about Scrum Mate and what difference it can make for you?

See what Scrum Mate has in store to help teams and organizations in moving faster.

What makes a good product owner?

Mon, 17 Aug 2020 00:00:00 GMT

What makes a good product owner?

Transforming user needs into well-written user stories is just a small fraction of all the responsibilities, traits and skills that come with being an outstanding product owner.

Unquestionably, being a product owner is a daunting role and mastering the profession requires well-developed abilities in many areas. As their role is fundamental for successful agile teams, we want to highlight five of the most important areas where a great product owner should excel in.

Misinterpretation of the product owner role

First, it's important to clear out a few things as there are various fallacies about what product owners should do.

For example, a common but flawed interpretation of a product owner's job is that their responsibility is to collect stakeholder requirements and transform them into well-specified product backlog items that the team can use to develop an appropriate solution. At the end of the sprint, the product owner inspects that the product increment developed by the development team meets the specified requirements.

Wrong.

What are the problems with this description?

1.) It implies that it is the client's job to define the characteristics and the features of the desired solution and that the PO's duty is to accurately record what the customers say.

Why is this wrong?

Because in practice, customers usually have minimal skills in defining solution details and requirements. What they can typically explain is not what the outcome should be but their pains and desires. They have no experience to elicit and define requirements in a precise way. It's actually extremely hard to understand and define the solution that satisfies their needs upfront.

Often, latent requirements come to the surface only when customers first try the solution built upon their initial demands.

Researching, imagining, and ultimately designing the best feasible solution is a collaborative and joint effort between the stakeholders and the development team.

The primary role of the product owner is to foster constructive, purpose-driven communication between stakeholders and the development team that can lead to a shared understanding of what stakeholders need and what is feasible within the given constraint of the project.

Sometimes, both stakeholders and developers are reluctant to talk to each other due to their different background, their limitations of time, or just because they find the discussions too slow or overwhelming. The PO's job is not to transport the information between developers and stakeholders, but to connect them and help them overcome the communication barriers so that they can get a shared understanding of what needs to be built and why, as well as what are the possible options to actually build the solution.

2.) It implies that it is the product owners' job to transform stakeholder needs into ready-made detailed solution requirements for the development team.

No, the product owner is not in charge of defining the requirements on her own. She involves many people in this process, often members of the development team.

It's OK for a product owner to explore stakeholder requirements earlier than the rest of the team, but it's a misconception that a PO is in charge of setting all the requirements for them.

Instead, the PO's job is to empathize with the pains and needs of the stakeholders and act as a representative of those needs in the team. In hindsight, the PO is not the one that defines the requirements but makes the underlying needs and pains clear and facilitates the discussions within the teams to unearth the requirements that should be met.

The product owner might be the one who leads the requirement discovery effort, but she is not there to present ready-made requirements for the team.

3.) It implies that the product owner is separated from the development team.

The Product Owner is a whole-hearted member of an agile team, not a client of the developers.

The product owner's job is not to place orders for the development team and accept or reject the solution delivered by the team. Instead, she should work closely with the team members to ensure that they are equipped with the necessary understanding of the requirements and the underlying needs behind them, so that they can make proper implementation decisions when needed.

Skills of a great product owner

As we mentioned at the beginning of this article, being a product owner could be overwhelming. Actually, to be an ideal product owner, one should be kind of a jack of all trades and encompass the traits of all the following roles:

Leader. The product owner has a vision about the end product and can communicate it in an inspiring way. She can win and inspire developers and stakeholders, so they don't just want to survive the project, but actually thrive on building the envisioned product and seeing it live. She can also make decisions when conflicting requirements or diverse concepts arise from different stakeholders.
Facilitator. Building a successful solution is a joint effort of all stakeholders, including the client, users, developers, and managers. Each group has its different expertise, skills, and valuable contribution to the project. They also have varying - sometimes even conflicting - expectations and desires.

An ideal Product Owner is a great facilitator who can bridge the gap between different stakeholder groups by facilitating communication, developing compromises, and coming up with novel ideas that can resolve conflicts.

The best way to build a shared understanding is by assessing and discussing the experience of using the working product. The product owner should always facilitate early and frequent delivery of working product increments to shorten the feedback loop between the stakeholders and developers.
Solution architect. To effectively facilitate discussions and make educated decisions, the product owner needs to understand the different aspects and cross-effects of those aspects towards the product.

Imagine the following situation:

The team discovers that new users often leave the product because they find the initial user experience is too overwhelming. To improve the onboarding experience of new users, the team could make the ‘xy' feature simpler. However, existing expert users require the advanced capabilities of this feature. A solution might be to introduce the complexity of the feature gradually, as users advance in navigating through the product. However, making the feature "polymorph" - that it works differently for different users - will increase the development and maintenance cost of future development efforts.

Here, the problem includes aspects of user experience, business, and technology.

As Martin Ericsson described in his article, "What exactly is the product manager?" the product owner should develop a sufficient level of understanding in the user experience, business requirements, and technical aspects of the product. Ideally, she should have a deep knowledge of at least one of these areas.
Guard. As Henrik Knieberg explains in his excellent video "Agile product ownership in a nutshell", every feature a team delivers generates new ideas and new desires from stakeholders. It's simply impossible to satisfy all the ideas that emerge during the project. It is the product owner's job to ensure that all stakeholders understand that there are limitations to the teams' capacity and that many ideas need to be skipped. In Henrik Knieberg's words, "the product owner's job is to figure out that of all possible stories in the whole universe, which four to six stories shall the team deliver next."
Fund manager. We like to think of a product owner as a fund manager. A fund manager's goal is to select the best stock portfolio to invest in and maximize revenue while minimizing risk. Product owners are faced with many ideas and requests to invest. The team has limited resources and the product owner has to select the best choices from the infinite options (delight existing users, impress new users, improve usability, add more features, and so on) to strategically invest the team's resources in a way that it maximizes the value of the investment.

To summarize, it's important to know and understand what the responsibilities of a product owner truly are instead of limiting the role to story creation and explanation. As you've been able to see, there's a lot more to product ownership than we can imagine.

It may look like the product owner must be a super-human. However, mastering this role is not an impossible task. The key is to understand that product owners are not only story creators, but also facilitators and successful communicators that highly value the importance of teamwork and transmit a deep understanding of the different aspects of the solution.

The Scrum Framework at a glance

Fri, 05 Jun 2020 00:00:00 GMT

Scrum framework at a glance

Scrum has become so popular, that many people confuse Scrum with agile. Needless to say, Scrum is not the same as agile, but one of the successful agile frameworks with a great impact on how agile teams operate.

The greatest merit of Scrum is that it created an easy-to-understand model for agile teams that includes practices, tools, and roles to navigate the organizational change towards agility.

If you're looking to read more about it, the most credible source of the Scrum framework is the Scrum Guide.

The theory behind Scrum

Scrum is built on the empirical process control theory, which claims that following a prescribed process in an uncertain environment is not a guarantee of results. As a consequence, the process must be adjusted as the team learns more about the problem.

This is why Scrum is not a methodology because every team needs to develop its unique system that suits their specific circumstances. Scrum provides the framework that specifies the essential elements and rules every Scrum team should apply.

To facilitate empirical process control, Scrum relies on three main pillars: transparency, inspection, and adaptation.

Transparency means that important aspects of the process must be visible for everyone whose decisions may affect the work. To ensure transparency, Scrum teams manage their work on a shared team board and make various visual representations (such as charts) of the progress publicly visible.

To ensure that the process applied by the team leads to desirable results, the team inspects both the end product and the process that led to the product at regular intervals. Based on the findings of the inspections, the team should adapt their process or product as soon as possible.

Scrum Team

The protagonist of the Scrum framework is the Scrum Team. As the framework borrowed its name from the rugby game, the Scrum Team is similar to a sports team; the members are committed to achieving a goal. The Scrum Team consists of 3-9 motivated team members. In Scrum, the team members are dedicated members which makes being a member of the Scrum team their primary role within the organization.

There is no Scrum without a cohesive team striving to achieve a shared goal.

Within the Scrum Team, the Scrum Guide defines three roles.

Everybody in the Scrum team who works on product development is a developer. Using the term developer for team members emphasizes the collective spirit of the Scrum team: "we're all here together to build a solution, and we all share the responsibility of achieving our goal". Software developers, testers, technical writers, and UX designers are all developers according to the Scrum terminology.

The Product Owner is the navigator of the team. The Product Owner has the best understanding of the business context of the product. The Product Owner knows the answer to the following questions:

What are the competing solutions?
What are the desired characteristics of the product from the end user's perspective?
What elements of the product should be implemented first, and what's next?

It's the Product Owner's duty to develop and articulate a clear vision of the solution.

The Scrum Master is the servant leader of the team. She is the one who fully understands the philosophy and driving forces behind Scrum and knows how to leverage the potential of the Scrum team. It's also the Scrum Master who ensures that the organization around the team understands the dynamics of Scrum and respects the autonomy of the team.

Scrum values

The Scrum framework is a set of values, principles, and practices that guide the Scrum Team on their endeavor to building a successful product.

The latest update of the Scrum Guide adds emphasis to the values that drive the behavior of the members of the Scrum Team.

The five values of Scrum:

commitment,
courage,
focus,
openness,
respect.

The presence of those values is vital to unleashing the potential of Scrum.

Scrum artifacts

During their effort in building the product, the Scrum team creates and maintains three artifacts.

Potentially Releasable Product Increment
Product Backlog
Sprint Backlog

Like most agile frameworks, Scrum advocates for an incremental and iterative development approach, that is the team builds the solution up in small increments and refines the product every time they learn something new. The goal is to produce a potentially shippable product increment at the end of each sprint. A product increment is potentially shippable if it meets the quality standards of the team - it's tested - and it's integrated with the existing functionality of the product.

The potentially releasable product increment is the most important artifact in Scrum.

The product backlog is the single source of all work things that the team needs to implement to deliver the product. The product backlog contains functionality that is required by the users, known bugs, functionality improvements, and engineering tasks. It's a constantly evolving and ordered list, that contains its items in implementation order. That is, a backlog item at the top will be implemented sooner than the item below it. The product backlog is visible for everybody (especially for the members of the Scrum team) who make decisions regarding the development. As the team collects everything that needs to get done during the entire product development in the product backlog, the sprint backlog contains everything that the team aims to deliver in the sprint. The sprint backlog is a set of product backlog items selected into the sprint, and elements of the plan the team created to meet the sprint goal.

Events in Scrum

The Scrum Guide defines five events that every Scrum team performs regularly.

The Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

All of these events are meant to serve transparency, inspection, and adaptation, the three pillars of Scrum we mentioned before.

To prevent wasting time and to boost focus, all events in Scrum are time-boxed, which means that every event has a maximum duration.

The most iconic element of the Scrum framework is the idea of sprints. The Sprint contains all other events and sets a steady cadence for the team. The length of the sprint sets a maximum latency in delivering new product increments and performing improvements through the inspection and adaptation cycles. Scrum limits the sprint length in one month with the preference of a shorter period. The most popular sprint length among development teams is two weeks.

The team sets their goal for the upcoming sprint and creates a plan to achieve that goal during the sprint planning meeting. It is also the team that creates the initial version of the Sprint Backlog on the Sprint Planning meeting.

The Daily Scrum is a synchronization event for the development team, where the team members plan their work for the next 24 hours and where they review their progress towards the sprint goal. The Daily Scrum meeting is held every day of the Sprint and its duration is limited to 15 minutes.

At the end of the sprint, the team and the stakeholders perform a Sprint Review where they inspect the Product Increment and adjust the Product Backlog based on the findings they uncovered. As a simplification, we can say that the team inspects and evaluates what they built.

After the Sprint Review, the team inspects itself in terms of performance, relationships, processes, and tools. Unlike the Sprint Review, the Sprint Retrospective is a private session for the team, where only team members are present. The Sprint Retrospective meeting reflects on how the team worked.

What to watch for when introducing Scrum?

Scrum scored itself the title of being the most popular agile framework, and for a good reason.

However, despite its unquestionable merits, the Scrum framework leaves many questions unanswered (some intentionally) and also room for misinterpretations.

The Scrum Guide is written in a rather prescriptive tone that creates the false impression of favoring a rigid behavior. Inexperienced Scrum Masters often borrow the prescriptive tone of the Scrum Guide and alienate themselves from the Development team and the rest of the organization.

A common criticism of the Scrum framework is that it doesn't provide any guidance for development teams in terms of practices and techniques. Although, this is intentional to leave the freedom for teams to discover and perfect their own custom method.

Scrum focuses on the Scrum Team and leaves organizational level questions unanswered.

Unfortunately, inexperienced leaders and coaches without a deep understanding of the underlying agile mindset often transform the former controlling culture into a Scrum-like hybrid model that miss most of the promises of real Scrum.

These failed transformations lead to an enormous loss in Scrum's reputation.

The agile model

Tue, 21 Apr 2020 00:00:00 GMT

The agile model

How is it that we can read so many success stories about life-changing agile transitions, but at the same time witness other organizations struggle with getting results from agility?

As a way to shed some light on this question, we gathered the most crucial traits of successful agile organizations into a simple agile model, based on more than a decade of experience in helping organizations to succeed with agile.

What we found is that it's not the applied agile framework (e.g., Scrum, Kanban, or XP) that makes the difference between success and mediocrity. It is actually the understanding and application of the principles and values behind agility that dictate whether an organization will thrive in agile or fail miserably.

Elements of an agile model

According to the Agile Alliance, agile is the ability to create and respond to change. The premise of our agile model is that the ultimate goal of an agile organization is to improve their ability to succeed in an unpredictable environment.

Different agile frameworks define different practices and focus on different values. However, if we dig deeper, we find that the following eight traits are always part of the culture of successful agile companies.

Early and frequent delivery of working product increments
Ongoing evaluation and prioritization of work to maximize value
Limiting work in progress
Emergent architecture backed with automated testing
Empowered, cross-functional teams
Transparency
Close collaboration between customers and developers
Safety, as a prerequisite

Let's take a further look into how these eight elements of the agile model contribute to the adaptability of an organization, and why their presence is indispensable in the creation of a corporate culture that can succeed in an uncertain environment.

Early and frequent delivery of working product increments

The most crucial attribute of agile organizations is their ability to deliver solutions early and often.

We can't understand a complex environment via analysis, nor can we develop reliable plans to cope with unforeseeable challenges.

Rather than elaborating theories about the nature of our business context, agile organizations actually deliver something and then test the reaction of the environment. They build projects based on empirical data instead of theories.

The more uncertain the environment, the more critical it is to explore via experimenting with working product prototypes. The findings of earlier experiments serve as an input for the next product version. The production, evaluation, and modification cycles are known as feedback loops.

The length of the feedback loops determines the adaptability of the organization. The shorter the feedback loop, the more adaptable (or agile) the organization is.

Limiting work in progress

If a team wants to deliver working product increments early and often, they need to narrow their focus on a limited number of problems. In other words, they need to limit the amount of work in progress.

Limiting work in progress is an essential principle of both Scrum and Kanban frameworks. Scrum limits the amount of work in a given timeframe with the sprint backlog, while Kanban sets explicit limits for the number of items in each phase (or column on a Kanban board.)

By focusing on a limited number of things, the team earns the capability to deliver small increments faster. This capability has several benefits.

Boosts efficiency by reducing the amount of partially done work and the cost of context switching. The organization creates value when they deliver a working, valuable product increment to the hands of the end-user. Work items that have been started but haven't been finished yet are investments without generating any value. Partially done work can be considered as a form of waste. Limiting the number of work-in-progress helps team members to avoid the cost of context switching. That is, when a team member needs to suspend a task and switch to another job, she needs to accommodate to the new context, which has a time cost.
Improves adaptability. By finishing and delivering work often, the team reduces the risk of leaving a work item unfinished as a result of unexpected changes in priorities.
It helps in avoiding capacity overload by enforcing prioritization. Working on many tasks at once leads to the false perception of making progress with many goals parallelly. The illusion of progress hides the capacity limitations of the organization, so decision-makers won't realize that the organization has already reached its potential, and they keep pushing more and more tasks on the organization. By limiting work in progress, teams won't start a new job until they finished something. As a result, queues of desired work will begin to pile up waiting for the team, which will make capacity constraints clearly visible. Visible constraints trigger deliberate prioritization, which helps the organization to concentrate on the most valuable work.

Ongoing evaluation and prioritization

The premise of traditional project management is that we can define our end goal upfront, which makes it possible to design a process that is optimized for maximum efficiency.

But what if we can't be certain about the outcome or the stages of the development process? What if we know that some parts of the product will be more valuable than others, and there will be some requirements that we have no information about at the beginning of the project?

In these cases, we can't optimize our plans to minimize the implementation cost, but we'll need to define small increments and select the one that provides the highest value according to our understanding.

Once we build and test the most promising increment on the target environment, we'll reassess our plans and select the next most valuable increment, based on our most up-to-date knowledge.

As we release new versions of the solution, we learn more about our environment and face new challenges and new opportunities. Each discovery can be a potential sign that we need to change our plans.

So, an inevitable element of agility is an ongoing evaluation and prioritization process, which ensures that we move forward with choosing the most promising investment at the time.

Emergent architecture backed with automated testing

To deliver solutions as early as possible, agile teams focus their efforts on the most valuable elements of the solution first. As a first version, they build the simplest possible solution.

Let's see an example.

Imagine that your team will build a new webshop. A webshop has several features, like the option of browsing products by visitors, managing stocks by warehouse department staff, and creating and handling sales campaigns by the sales department.

Let's say that the team wants to start with the browsing experience of first-time visitors because they believe that this feature will be the differentiator that makes this particular webshop stand out.

The idea of emergent architecture is that no elements will be built into the first version of the system that aren't required to make the browsing experience of first-time visitors work.

Since they focus on first-time visitors (not returning customers) in the first version, there is no need to implement an algorithm that suggests products based on previous orders of the customer. The team knows very well that suggesting relevant products to a returning customer will be an essential part of the webshop, but they still don't implement it in the first version.

Why?

The emergent architecture approach allows the team to keep the product simple. With a simple architecture, they can move forward faster. Also, a smaller and simpler code is easier to modify if it turns out that the initial ideas are flawed.

What are the risks of emergent architecture?

As the notion "architecture" suggests, it needs to be rock solid. Building a decent architecture in an emergent way requires disciplined engineering practices. Often, the team needs to redesign and reassemble some parts of the solution to satisfy new requirements.

To keep the solution stable, each increment requires thorough testing. Since an agile team makes changes in the code often, regular testing can quickly become a bottleneck and a considerable cost factor in the process. A crucial part of emergent architectures is automated test suites that ensure that modifications of the code don't introduce bugs to the system.

Empowered, cross-functional, self-organizing teams

In a turbulent environment, organizations need to make and execute decisions as quickly as possible. This can't be done with large organization units and bureaucratic, centralized decision-making procedures.

Small teams with no more than 12 members are the best in coping with complex situations and making deliberate decisions quickly. Teams focus on a well-defined goal. They take full responsibility for a product or an aspect of a higher initiative. Team members must clearly understand how their efforts contribute to the success of the company - or even better, to the wellbeing of humankind. The more engaging the goal is, the better.

To ensure responsiveness, teams should be as independent of the rest of the organization as possible. Agile teams are empowered and self-organizing; that is, the team members make most decisions. Rules and processes that drive the team are defined by those who are closest to the problem, not by top-level management.

To support self-sufficiency, most agile teams are cross-functional, that is, they're made up of people from different working areas so that they can deal with all the functional aspects of a solution.

Close collaboration between customers and developers

Agile organizations strive to deliver the highest possible outcome to their customers. However, in an uncertain environment, the solution that provides the highest possible outcome can't be defined upfront.

As the team is progressing in the project, they discover new opportunities, new challenges, and new options. The customer has the best understanding of what output provides the most significant value for their goals. On the other hand, the development team has a better understanding of the available implementation options, costs, and risks.

To keep steering the project towards the most beneficial direction, the customer and the development team need to maintain a shared understanding of what's going on, and where to go. To keep up with that shared understanding, customers and developers need to work closely on a daily basis.

No detailed plans, nor carefully written contracts can replace the constructive collaboration of developers and clients.

Transparency of important aspects of the process

Agile frameworks build on empowered and self-organizing teams, formed by motivated individuals. Since teams are self-organizing, the development process is not controlled by a single manager; instead, it's the shared responsibility of the team members to manage the development efforts and make decisions.

The collective ownership of the development effort could quickly turn into chaos if the team members don't agree about the essential aspects of the project. The most important aspects of the process are goals, measures, activities, and working agreements.

To build an agreement based on shared understanding, they need to access the same information that is relevant to the work. Also, they should maintain a single source of truth that is easily accessible to all members who contribute to the success of the project.

In other words, important aspects of the process must be transparent for all involved in the development process. Software tools used by agile teams serve transparency. Organizations often misinterpret the goal of an agile project management tool. The primary purpose of agile tools is to provide transparency, not to control the development process.

Safety

Agile is not a magic method that gives wings to teams per se. Agile teams lean towards high performance by continuously uncovering new ways of working. They use their creativity to find better ways of solving problems.

On their way to exploring new - or even revolutionary - approaches, teams sometimes fail. In fact, failure is an unavoidable inherent part of innovation, so it is to be agile. There is no agility without establishing a safe working environment.

To succeed with agile, safety must be established on the following levels.

Social safety around the teams. The organization must accept that the best-performing agile teams sometimes end up with a conclusion that their initial concept didn't work.
Social safety within the team. To establish an atmosphere where team members feel encouraged to come up with novel ideas, safety must be a prerequisite within the group.
Safety at the engineering level. Although we acknowledge that risk is a natural ingredient of innovation, the team must do everything humanly possible to design and build a protected ground where the effects of failures can be minimized. The ongoing endeavor to technical excellence and extensive use of automated tests are typical ways of creating safety around the solution.

What are the potential benefits of agile?

Don't expect that implementing agile practices will turn your organization into a hyper-productive value generation machine in 2 weeks. That may be an outcome for the long-term, but only if your teams develop unique and efficient solutions to provide exceptional value to your customers.

And this is the key advantage of agile: increasing the chance that your organization can outperform your competitors by recognizing, understanding and generating change smarter and faster than your competitors, through the work of courageous and creative teams.

To support this goal, when done well, agile can introduce some more predictable benefits. Agile can improve the return on investment (ROI) of the development efforts due to the following reasons.

The early and frequent delivery of working solutions improves ROI since it reduces the elapsed time between investing in a development effort and delivering the results.
The ability to evaluate our ideas via testing working solutions in a real-world environment minimizes the risk of wasting our investments by developing features that nobody needs.
The ongoing value-centric prioritization, along with small increments, helps us to deliver the most valuable elements of the solution at the earliest possible time. As a result, we can enjoy the benefits of our investments from the first moment. Agile can significantly increase employee satisfaction and reduce employee churn.

An agile mindset helps the organization to implement a safe working environment, where work has an igniting purpose and creativity can flourish. This makes working for a real agile organization an asset for motivated employees.

Increased operational safety is an often-overlooked benefit of real agile organizations. This benefit comes from the team-oriented nature of agility. In a self-organizing agile team, individual responsibilities and the overall progress of the team is transparent for all team members. This setup reduces the risk of any team member becoming a single point of failure by being the only one holding sufficient knowledge in a specific area.

Where can I learn more?

There is no single definition of agile. There are, however, some widely accepted values and principles that drive high-performing agile teams, and there are proven frameworks that helped many organizations to succeed with agile. Our agile model is an attempt to collect the essential pieces into a single compilation. By reading an uncountable number of articles, whitepapers, and guides, we gathered the most valuable resources we've found below.

The agile alliance's introduction to agile
The agile manifesto and the 12 principles behind the agile manifesto
The guide to the Scrum framework
Simon Powel's model to explain what is agile
The Modern agile initiative
The Heart of agile approach

Tools for remote agile teams

Thu, 09 Apr 2020 00:00:00 GMT

Tools for remote agile teams

As productivity tool developers, we are obsessed with great tools that help agile teams become more efficient. We all learned that the ideal setup for agile teams is co-location, however, we're witnessing that remote work is becoming the norm. In this article, we collected some great tools that help remote teams maintain a high-bandwidth communication and succeed with agility.

An agile tool to plan and track teamwork

Remote teams can't use a big physical board with post-its to plan and track their work. We developed Scrum Mate to provide a powerful collaboration tool with real-time updates for agile organizations and their clients. With Scrum Mate, you can collaboratively manage product backlogs, run Scrum Sprints, or work with a Kanban flow. Scrum Mate keeps track of the most important measures of progress.

Messaging tools

The key to using messaging apps is to agree about your availability and response time on each platform. Don't expect an immediate response on messaging platforms since it will develop a habit for team members to keep their eye on those tools, and could significantly increase distraction and vanish personal productivity. Our go-to platform for messaging is - no surprise - Slack. The best thing about Slack is that we can collect all of our messages on a single platform. Messages from our team members and notifications from our other tools. Collecting and organizing everything onto a single platform has its risks, though. It's too easy to mess things up in Slack and important messages to sink in the mass of the message noise. What is excellent about Slack is that you can customize its notifications very precisely, so you can make sure that you get information about messages that are important for you. There are three alternatives to Slack on our radar.

Google Hangouts Chat is a serious contender, mostly because there is a collaboration tool giant behind it. It feels less refined than Slack, so for us, the only reason to consider switching from Slack is that Hangouts Chat is part of Google's G Suite, so it's included in our Google subscription.
Microsoft Teams is a straightforward solution for Microsoft Office 365 Business Standard subscribers, and worth considering for others too. It's an all-in-one collaboration tool that includes messaging, calls, meetings, and collaborative editing of various Microsoft document types.
Chanty is a more affordable alternative to Slack, with a smaller but highly satisfied user base, achieving top rankings on review sites.

Tools for virtual meetings

As the 6th principle of agile software development claims, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

For simple, ad-hoc virtual team meetings, both Slack, Microsoft Teams and Chanty can provide group call features. You need to subscribe to a premium plan to access those features.

If you need more control over the meeting, or you want to invite a large number of attendees - to a sprint demo for example - virtual conferencing tools are the solution.

Google Hangouts Meet. If we want to discuss something with our team, we use Google Hangouts. It's part of the Google Apps suite, and it does almost everything you need for effective team collaboration. It mostly provides a pleasant voice and video quality and offers screen sharing capabilities. You can exchange comments with your team members in the chat window. It has its shortcomings, though. What we miss most often is the ability to share a document in the chat window. Be careful with dropping a file to the chat window from your desktop because it will open the document in the browser and terminate your hangouts session, so you'll need to re-join again.

Zoom is an excellent alternative to Google Hangouts, especially if you want to involve more people than just a small team. It's an advanced video-conferencing tool with a bunch of useful and even fun features. Just to name a few, Zoom allows participants to virtually raise their hands, record meetings, and conduct polls. It offers excellent video and voice quality and uses your bandwidth sparingly.

Tools for documents and memos

There is room for more than one documentation tool in your team's arsenal. Google Docs is our primary documentation tool for adding details to our user stories in Scrum Mate. Whatever project management tool you use, it'll be far behind Google Docs in terms of real-time editing and simplicity. We prefer Google Docs over wiki solutions because everybody understands how to use it, so it's easier to collaborate with our clients. Since almost everybody has at least a personal Google account, it's easy to share and collaborate with stakeholders around the project. Other tools that can be a great addition to Google Docs.

Dropbox Paper is a fantastic tool for writing meeting memos and sharing ideas with your team members. If you want to add voice or video to your documents easily or prefer a dark mode, then you should definitely give Dropbox Paper a try.
Notion has defined a unique, all-in-one category for collaboration. It's a great lightweight tool to organize memos, documents, todos in a shared knowledge base. Unlike Dropbox Paper and Google Docs, it's a standalone solution, not a part of a suite, so it can become a bit pricy.
The good old Microsoft Word is still the best platform to create well-formatted documents. No other tools compare to Word in mixing visual flexibility and collaborative editing.

UI design tool

We're a big admirer of Sketch, a tool that we think revolutionized software UI design. We've used it for years and still love it. However, when we were forced to work remotely as a result of the Covid-19 pandemic, we started using Figma, as it allowed us real-time collaborative editing from remote locations. We were amazed at how well it does the job, and we'll most likely stick to Figma in the future.

Virtual whiteboard tools

Getting together around a whiteboard is the best way to develop and share ideas with lightning speed. Whiteboards are essential tools for brainstorming sessions and retrospectives. No virtual tool can fully replace a whiteboard, but some do a reasonably great job. We found two solid solutions at the time of writing this article. Both of them do a fantastic job and offer excellent collaborative drawing and diagraming. To get close to the experience of physical whiteboards, you'll need a touch-screen device with a bigger screen, like an iPad.

Miro provides an excellent solution for collaborative drawing and diagraming. You can work on the same canvas with your team members, just like you were in front of a whiteboard. Also, it provides video conferencing capabilities and unlimited viewers for your boards.

Mural can provide basically the same features for you, as Miro. Here is a short comparison if you'd like to learn more about the differences between the two tools.

Although, Milanote does not offer free drawing capabilities like Miro or Mural, we still think it deserves a place in the virtual whiteboard category. Your creative team would probably love how easy it is to collect and organize ideas with Milanote boards with real-time, collaborative editing. But, if you're an iPad fan like us, you will probably miss a native iPad app.

In general, these are some of our preferred options, however, whatever tool that could help your team become faster and more reliable, will be the best tool for you. We hope you found our options interesting.

Be careful with agile tools! They can ruin agility.

Wed, 11 Dec 2019 00:00:00 GMT

Be careful with agile tools! They can ruin agility.

Contrary to popular definitions, Agile is not a methodology, it is a culture. One that is created and nurtured by specific values and behaviors and not defined by processes or tools.

Actually, implementing strict rules and complex tools will likely deter organizations from achieving agility.

Helping agile teams on their agile adoption journey for more than a decade, we came to the conclusion that four of the key ingredients of the agile mindset becomes endangered by so-called "Agile Tools":

Self-organization
Transparency
Focus and creativity
Adaptability

Unfortunately, these four traits are often bypassed when middle-managers advocate for enterprise-grade tools that present the illusion of "control", rather than driving the team to success in an agile mindset.

A common scenario that we've seen in many organizations is that managers ask team leaders to find a solution for handling projects and work. Through their research, teams often select highly customizable and complicated tools with known names, with the misconception that those will bring the best agile practices to their team.

The issue is that: rather than facilitating agility, tools often ruin adaptability, a key ingredient of successful agile teams. Overly complicated tools add bureaucracy and feed into the controlling environment that is against the core values of agile.

From our experience working with all types of companies and organizations, we've encountered the following problems when implementing enterprise-grade "agile" tools.

Here are 4 of them:

1. Replacing consent with control

Most managers like the idea that they can regulate productivity with strict workflows, easily enforced by the work management tool. Sloppy (or inattentive) team members often break agreed rules either intentionally, or unintentionally.

To stop deviations against processes, it's easier to set up a rule in the tool than establishing strong agreements about certain standards within a team.

There is nothing wrong with using the Tool's capabilities to warn a team member if she is about to mistakenly break an important agreement. The problem arises when the default answer to irregular behavior becomes: let's set up a rule in the Tool. This practice transforms important team values such as empathy and shared understanding, into regulations and control.

2. Sacrificing transparency for process compliance

As a carefully configured Tool can be a viable solution for assuring process quality, it often comes at the cost of decreasing transparency. Unexpected situations and changes could prevent teams from complying with the preset processes in the tool.

For example, if a team member with the appropriate access level to move an issue to a certain stage goes on a sudden leave, strictly configured tools make it difficult for other members to make changes to the issue status.

The result: the issue stays in the current state and there's no accurately updated information about the process. In turn, instead of being an up-to-date source, the process set within the tool is preventing the tool to serve an important value of agile: transparency.

3. Luring the teams focus away from valuable work

Tools become incredibly clever and sophisticated these days. The possibilities for customization are endless. When configured appropriately, the tool offers a solution for almost every possible situation. Moreover, becoming an expert in The Tool turns into a valuable skill in the labor market.

The Tool becomes so interesting, that the creative energies and productive time of the team are spent on hacking The Tool to make sure its capabilities are fully utilized. The tool becomes a goal and the team constantly split their attention between tuning the Tool and delivering valuable work.

Often, time is allocated to work on the specs of the tool just because the tool provides a specific possibility - rather than because it is a needed step for a process. When, which is not so uncommon, a tool can't be configured to support a unique idea of the team, they may abandon the idea.

Instead of serving them, The Tool starts to rule the team.

4. Favoring conformity over autonomy

Once a company invests a good amount of money in a sophisticated tool (that promises never-before-seen transparency and a sense of order), they try to solve everything with the tool. When the company tries to manage everything with a single tool, it will face interdependencies and conflicts in process requirements across teams.

The solution?

A dedicated Agile Tool administration team, which is responsible to maintain the organization-level integrity of the system.

As it is usual, someone from the IT Department will be in charge, which takes ownership of the tool away from the development teams' control (ironically, the team will need to submit a ticket in the Tool for the Tool administration department to modify the setup of the Tool).

This situation attempts against agile's core value of "autonomy". Because the development team now depends on a third-person to manage specific aspects of their own process, there's a lack of flexibility and the adaptability and productivity of the team slow down.

Summing up

We have listed various reasons why we believe that some Agile tools could really hurt agility and prevent teams from a successful adoption of the agile mindset.

Although teams could configure complex agile tools to be more permissive, the tool itself is still unfriendly because it is designed to limit freedom and enforce processes.

As we said in the beginning, becoming Agile is more about getting immersed in the right values as a team, with the goal of moving towards the successful delivery of work.

Our advice is that organizations shouldn't expect tools to make their teams more agile, as the more they rely on a tool, the more rigid it will make the process. Instead, focus on the core values of agile and in finding a tool that works without slowing the team down.

GitHub integration

Tue, 29 Oct 2019 00:00:00 GMT

Introducing Scrum Mate's GitHub integration

The new Scrum Mate GitHub integration is now available. A few weeks ago, we silently released a new way to attach documents to story cards and tasks, which allow you to add documents just by pasting their URLs.

That new attachment method paved the road to our first GitHub integration feature.

From now on, when you paste a URL of a GitHub issue, branch, commit or pull request, Scrum Mate will recognize a GitHub URL and turn it into an informative preview.

To access the GitHub previews, you need to connect your GitHub account to Scrum Mate.

When you first encounter an attached GitHub URL on your story card, click on the 'Connect your GitHub' account link to allow Scrum Mate to present more details of the GitHub data.

If you ever want to disconnect your GitHub account, go to your settings page, select GitHub and click on 'Disconnect' button.

What would you like to see improved?

We'll add new integrations in the future. Let us know if you'd like to see any particular integration option. You can always add your ideas and vote on requests posted by other users on our feedback page. We can't wait to hear from you.

Public API

Fri, 27 Sep 2019 00:00:00 GMT

Introducing the Scrum Mate API

We're happy to announce that the public beta of Scrum Mate's REST API is now available! It lets you integrate Scrum Mate with your existing tools and workflows. With the new API, you can manage stories, tasks, worklog entries, projects, teams and more.

To get started, you'll just need to create an API Token on the organization settings page. (Please note that you need to be an admin or an owner of the organization to create an API Token.)

For the full reference of available endpoints, please check out the developers documentation.

As this is only the first version of the API, we'd love to learn more about how to make it a better fit to your needs.

If you have any improvement ideas, please don't hesitate to share them with us on our integrations feedback page, where you can also vote on suggestions submitted by other Scrum Mate users.

Professional services with an agile mindset

Wed, 07 Aug 2019 00:00:00 GMT

Professional services with an agile mindset

When working with creative or software development companies, transparency is the main ingredient to achieve successful client-developer relationships.

If you currently work for or employ within this industry, I suggest you continue reading.

The main question for outsourced software development endeavors is how can a solution provider dedicate a team for each of their development projects? And secondly, how to create a trustful relationship between clients and developers?

At Scrum Mate, we have seen that it is possible to successfully embed an agile mindset into the relationship between the client and the solution provider. In fact, we are certain that adaptive, agile software development has the potential to deliver more value to the client than traditional, prescriptive models.

In this article, we'll present a model that helps solution providers and clients to build long-term, and mutually fruitful relationships based on the agile mindset.

It's not the execution of the project plan that matters

We don't implement projects for the sake of building products. A product is meant to solve issues, simplify processes and serve an underlying business need.

The first step towards improving efficiency with an agile mindset is to shift our focus from output (i.e. features prescribed by initial concept plan) to outcome (i.e. improvements in business goals). And we want to get more outcome, not more output.

Once we identify the business goals we want to improve - the outcome -, we need to accept that at least to some extent we have no reliable knowledge about how to build a product that meets those business goals.

Here, we find ourselves in front of two sources of uncertainty.

The first one is that we have no experience in building a solution for that specific business need in a particular business environment. In other words, we don't know what to build.

And the second one is that we may have no experience in working together as a client with a developer. In other words, we don't know how to build it together.

Even when we defined the characteristics of the product, we still won't know how it will turn out, or if it will work as we imagined in the conceptualization. We will need to wait until it is used when it's out in the market, and oftentimes, the first experience will be disappointing. At this point, we'll need to keep trying, delivering, and validating product increments frequently and often.

Agile development is all about customers and developers working collaboratively and exploring ways of creating successful solutions together.

Facing high uncertainty, the success of the project will depend on the team's ability to quickly discover and deliver formerly unknown requirements.

The faster we deliver, validate, and adapt, the higher our chance to meet business goals.

Development iterations must be short.

In a learning environment of short iteration cycles, experimenting will yield various options and claims.

Short release cycles and emerging demands for product changes require ruthless prioritization.

Here is the thing.

Real prioritization happens when there are solid and respected limitations of what's possible. Prioritization is about trade-offs.

Prioritization is not about deeming and saying that work is important. But about identifying what you're willing to sacrifice to ensure there are enough resources to focus on that important work.

Constraints are essential ingredients of agile development.

In fact, agile developments use even more constraints than traditional development methods. The difference is that in agile, we know that we often need to drop some of our initial requirements and replace them with new features to maximize the value delivered.

To make good decisions about priorities, clients and developers need to develop a shared understanding about the available options, their costs, expected benefits and the given constraints of the project.

The main problem with the conventional client - solution provider communication methods.

To succeed with agile development, the business project team - client and service provider together - need to deliver and validate working product increments on a frequent basis. A common practice is agreeing on a weekly or bi-weekly release rhythm.

Once agreements are set up, then we can add the secret sauce of agile: The business project team needs to select an appropriate volume of work that fits in the next iteration. That's a limited amount of work for which they will need to prioritize.

Prioritization should be driven by the client. In perspective, clients must have a clear understanding of all the work that should be done to make an educated decision about what to select to implement next. They also need comprehend the limitations of the next iteration.

In contrast to the desired transparency of options and constraints provided to the client, most projects employ a different kind of communication mechanism: ticketing systems. Customer ticketing systems allow customers to send their requests to the developers and attach severity properties to their tickets like "critical", "urgent", "normal", etc. Sometimes they can also set expected due dates.

Those ticketing systems are similar to an opening on a wall.

Customers can toss their requests through the opening or throw them above the wall, but afterwards they have very little information about what happens with their requests on the other side of the wall.

In those "behind the wall" situations, clients lack the transparency about the work that needs to get done and the limiting constraints. Their experience is that they throw their requests through the wall and they receive results in a less than satisfactory speed.

Because clients have no information about what's happening on the "other side" of the wall, they easily get anxious and impatient. This process can result in stricter deadlines and qualifying their requests higher on the criticality scale. This increases the pressure on the development team, creates a sense of urgency and could cause the team to miss quality standards.

If you want to overload and demoralize a team, this is one way to do it.

Stopping this vicious circle can only be achieved by providing full transparency to the clients and transferring the duty of prioritization to the customers.

To improve transparency, it is best to keep a simple list of all the pending work. It should contain details about what the team is working on, and what hasn't been started yet. Yes, what we need is a backlog. The backlog is the common, single source of truth that lists the work that needs to get done, and it's accessible for both the clients and service providers. The order of the items in the backlog defines the order of implementation.

Clients can add new requests to the list and reorganize the backlog based on their current priorities at any time.

The shared backlog allows customers to set realistic expectations by implanting transparency in everything that needs to get done. By having a detailed backlog with priorities set in a disciplined way, we can avoid misunderstandings, such as missed deadlines or flawed planning. As we said before, transparency is an important component of success as it leads to trustful relationship between clients and service providers, which in turn results in better decisions and higher productivity.

How to create viable plans?

Going back to the core of agile development: frequent delivery and evaluation of product increments. Most teams set up a weekly or bi-weekly cadence of releases.

The main question of the planning process is what can fit in the next iteration?

Let's use an analogy to put it in context.

Imagine, that your backlog is a collection of physical papers and models, and implementing them is comparable to delivering them by boat from one side of a lake to the other. The boat is paddled by members of the development team and each iteration is a trip between the two sides of the lake.

The boat has limited capacity to load packages and documents. So, it is important to prioritize what needs to be loaded in the next trip.

To develop a foresightful plan, we can create groups within the backlog to present milestones. We have a rough plan about when, and what features we want to deliver.

At this stage, our schedule is only a wish-list.

To create viable plans, we need a reliable forecasting method and we must determine how much work a team can deliver within the time limits of the selected cadence.

Let's say our desired delivery rhythm is one week. The question is, how much work can a team accomplish within a week, without sacrificing quality standards.

Estimating work

The problem with estimating creative work is that it's impossible to predict how much time it will take to complete the work. Three hours or four and a half? Nobody knows. The only responsible forecast we can provide is saying that a developer can probably complete this work in a half day.

The best way to estimate creative work is using "estimation categories" that represent orders of magnitudes. Using estimation categories speeds up the estimation process and reflects the uncertainty of estimated values.

As an example, here is the estimation scale that our team at Scrum Mate uses.

The first category is the most common development work in our team. It may need around 2-3 hours of uninterrupted, fully concentrated work to implement a backlog item of this size. In reality, it often takes a half day to complete a work like this. We refer to stories of this size as a standard 1-point work. We say that the size of this backlog item is one story point.

The second category is about twice as big as the first one. It's a 2-points sized work. It requires 4-6 hours of uninterrupted, fully concentrated work to implement a backlog item of this size. In reality it usually takes almost a day. Sometimes less, sometimes slightly more.

If we continue going up, a backlog item that is estimated to 5 points may require 10 - 15 hours of fully concentrated work. To implement a story of this size may take usually two, sometimes close to three days.

More than 90% of the work our team starts working on fits into one of the categories between one to five points. The rest is smaller than one point, meaning that it takes around an hour or less to complete it.

We try our best to avoid working on stories that are 8 points or larger. We decompose those backlog items into smaller chunks before starting to implement them. A story in the 8-points category can engage a developer for a whole week. They are too big to oversee their complexity and can cause unpleasant surprises.

You probably noticed that we define required effort in ideal working hours, that is uninterrupted and fully concentrated time spent on a task. No star-gazing, no questions, no problems - just effective work. The equivalent of 6 hours of fully concentrated, uninterrupted, ideal work is around one workday.

We're not ashamed to admit that we have only a rough idea about how much time it will actually take to complete a backlog item.

However, with the estimation categories described above and the forecasting mechanism that we will explain next, we can anticipate fairly well how many backlog items we are able to implement in the next week or two.

Creating forecasts from estimates

The best way to forecast the future is to learn from the past.

For example, we may see that in the past, the team was able to deliver 50-60 story points per week. Knowing this, we can assume that the team will be able to deliver the same amount of work in the future. This is what we can identify as the velocity of the team.

Going back to our boat analogy, if we load an estimated 50 story points of work, then we can deduce that team can ship it within one week. While if we try to ship 80 story points, it will take more time to reach the other side of the lake.

We need to be careful with forecasts and recognize the capacity limitations of the team. Just like the boat has its load capacity, try to put too much work on the boat, we'll exceed its bearing capacity and it'll become iffy and slow, it could even sink.

Once we have enough data from the past, we can see that the team's velocity varies within a certain range. And still then, what happens in reality depends on various factors: the complexity of the work, a less than ideal environment (more interruptions than usual, there was a flu epidemic) or some of the team member's individual performance was lower than usual.

Those factors altogether can easily result in a +/- 25% variance in the team's actual velocity on the actual iteration.

The variance in the team's velocity is unavoidable, and it should be clear for the business project team.

Agile team working on many projects

Agile frameworks suggest that a team should be dedicated to a single project, which we think is wise advice.

However, dedicating teams to a single project is not feasible for professional creative services companies. If we dedicated a unique team for every client or project, we would lose our ability to adapt to the changing demands of our clients. A team dedicated to a single client would be either overloaded or underutilized most of the time.

Teams of agile creative service providers need to cope with more than one project and client at a time. This is the only way we can maximize the potential of the company.

Even if a team works for many clients, there are a few principles we need to comply with to obtain the benefits of agile.

Agile teams are self-organizing, meaning that team members have all the knowledge and authority to decide how to get the work done. Nobody from outside the team has the same level of understanding about the problem, so no one outside the team has the authority to command team members. It doesn't come without responsibility, team members are accountable for each other and this mutual accountability drives agile teams forward.

To enable self-organization, all team members must have all the knowledge to make decisions and hold accountability. Transparency is provided by the team board that contains every backlog item the team is working on.

To support sustainable performance, it's crucial to maintain the balance between workload and capacity.

There is a bullet-proof way to ruin the productivity of a team: long-term overexertion.

Unrealistic deadlines and impractical volumes of workload lead to burn-out, low quality products, and defects which generate critical issues - a vicios cycle so to speak.

When a team serves many clients, they will face an extreme pressure caused by the continuous stream of requests from clients. We need to manage this pressure to avoid overloading the team.

The best way to manage pressure is to switch from a push model to a pull model, where the team can pull work from the prioritized backlogs prepared by clients and account managers to their board.

Agile teams don't need managers to select the work they can presumably deliver during the next iteration. They need clear priorities and guiding principles for selection. According to the 5th agile principle, we need to build projects around motivated individuals and give them the environment and support they need, and trust them to get the job done.

This is how you can implement the pull model with an agile team and many clients.

Create an intermediate area, where every client (or their account managers) can place the backlog items they want to implement next. This intermediate area serves as a lock between the team's board and the flood of requirements from clients.

The advantage of this lock area is that it presents an already filtered amount of work for the team, so they need to deal with a manageable volume of tasks when pulling work to their boards. Also, teams and clients (via their account managers) can agree on the limits of the intermediate area. Let's say they can agree that every client can add up to 20 story points work as not to overload the boat .

In our agile team collaboration tool designed for teams working with multiple clients, we call this lock area the 'Planbox'. Business stakeholders (e.g. clients and account managers) can add their most urgent requests to the 'Planbox'. The team can then access the unified view of the 'Planbox' sections of all connected projects and pull work directly to their board.

To sum up

Building a customer - service provider relationship upon an agile mindset has vital advantages for both parties.

To make it work, there are only a few principles to comply with.

Here they are.

Let's give up the innervation that the goal of the project is to produce an envisioned product. The goal is to improve the business. The product envisioned upfront is a potential solution to improve the desired business metrics, but it's potentially flawed.

Set up a business project team from the representatives of the customer and solution provider and define the constraints within the project team aims to deliver the anticipated improvements in the selected business metrics.

The likelihood of success will depend on the project team's capability to explore the characteristics of the successful product and the project team's ability to learn how to build that product in cooperation. Both require frequent delivery and evaluation of working product increments.

Frequent delivery and evaluation of working product increments will open the way for countless new ideas. The required effort to implement all the initial and emerged ideas will far exceed the boundaries of the project. The project team needs to carefully select what features to implement, what to postpone for later iterations and what to give up entirely.

The success of the development will depend on effective prioritization rather than on the implementation of the original project plan.

Prioritization means ruthless selection and painful trade-offs, but without setting priorities, the team would waste their resources on developing nonessential product features.

The right tool to aid prioritization is a backlog. The backlog is an ordered list of everything that is known to be needed to accomplish our goal. The backlog should be transparent and available for both the client and the service provider.

Agile solution providers employ self-organizing development teams. Unlike product development teams, service provider teams are working for more than one client, so they are not dedicated to a single project. This is to maintain their ability to adapt to the varying volume of work arriving from a customer.

Members of an agile development team need up-to-date information about everything that needs to get done and information about who is working on what. This transparency enables the self-organization of the agile team and it is achieved by representing all work that needs to get done in a single, visible board. The development team usually works on tasks from more than one client in parallel.

The development team owns the implementation process, and the business project team owns the identification, decomposition and prioritization process. In other words, the business project team owns the backlog, the development team owns the board. To make the cooperation smooth between the development team and the business project team, there must be at least one person who is a member of both teams at the same time.

To shelter development teams from work overload, agile service providers need to employ a pull system controlled by the development team. That is, business project teams can't push their requests to the development team, but they can place their issues to an interim area where the development team pulls work to their board. This interim area is called the 'Planbox' in Scrum Mate.

Clients and service providers should agree on the maximum amount of work allowed in the 'Planbox' and a service level for the average time within the team will deliver work placed on the 'Planbox'.

2019 Summer Updates

Wed, 24 Jul 2019 00:00:00 GMT

2019 Summer Updates

From the beach to the sandbox, we've been working on improving Scrum Mate this summer and we added new features that we hope you will find handy. Let's catch up on the most recent improvements that we've included!

New report: how many story cards are delivered per week?

You can analyze your project's delivery rate based on the number of story cards delivered in the past. This provides you a simple performance measurement method without estimations.

From now on, the delivery rate report is also available for teams.

Add multiple stories or tasks by pasting them from any text

Sometimes you write or receive memos containing a list of tasks or larger work items. Now, you can copy text from documents and paste each paragraph or list item as a separate story or task into Scrum Mate.

Create tasks or stories from a selected part of the story description

The description field of the story card became the perfect place to perform the decomposition of a story. Select any part of the description and create separate tasks or user stories from its paragraphs.

When you create new stories from the paragraphs, they will be immediately converted into links to the newly created stories.

Assigning members to tasks just got easier

Now you can add somebody (especially yourself) to a new task quicker. When you enter the name of a new task, type in the @ character in the task input field. Keep typing to narrow the list of the users and select the user you want to assign.

One more tip: you are always the first in the list. If you want to assign yourself to a new task, just type in @ and press enter.

Use filters in the calendar view

We introduced the ability to filter the team calendar view just like you do it on the board. To make it easier to navigate your calendar items, you can now filter to cards that are tagged with a particular tag, belong to a topic, or are assigned to a team member.

We hope you find these updates useful and that they improve your experience with Scrum Mate.

The Scrum Mate Model

Fri, 22 Mar 2019 00:00:00 GMT

The Scrum Mate Model

Our goal in Scrum Mate is to provide a great tool both for product teams and teams working on multiple projects.

We aim for our tool to benefit solution providers that manage and work for many clients, as well as agile business teams working on a variety of initiatives.

The Scrum Mate model is based on two cornerstones: projects and teams.

Projects are the goals and initiatives that are important to the organization. A project is broken down into actionable work items called stories. These stories are collected in the project's backlog ready to be accomplished by Teams.

In Scrum Mate, we define Teams as self-organizing groups within the organization who can work on one or more projects. To help them achieve that, they have their own board where they can organize their work.

A backlog represents the work that needs to get done

The backlog is the main workspace of a project and it provides a unified view of all stories that are yet to be delivered. As you will see, the backlog in Scrum Mate is divided into three sections.

At the top of the backlog, you will find a section called 'On board', which contains every story of the project that is on a team's board. The 'On board' section shows stories in completion readiness order: the most progressed story will be at the top of the list.

Then, you will encounter the 'Backlog' section which contains everything that needs to get done in the future. You will also find the 'Planbox' section that serves as a bridge between the team's board and the backlog section. The Planbox is a unique and essential tool to enable agile teams to work on multiple projects. We'll go more in depth about it a bit later in this post.

Since the backlog provides a comprehensive view of a project, you can use it as a single source of truth towards your clients. Your clients can get an overview of the progress of the stories of their projects to ensure transparency if you invite them to collaboratively manage the backlog.

Teams work on their own board

A board is a workspace that helps the team to visualize and organize all work they're completing. Every team has its own board that is set up by them to represent their workflow. Since a team can work on multiple projects, their board can hold story cards from many projects.

Note that the board can contain stories from many projects, and you may not want to invite your clients to a team's board. The board is for the development team only.

Agile for multiple projects

Agile - and especially Scrum - evolved in the product development environment where teams worked on a single product. The challenge when a team works on multiple projects is to avoid the chaos caused by conflicting interests of different projects that result in vague priorities and the loss of focus.

To sort that out, Scrum Mate uses a unique tool, called planbox. The planbox section in Scrum Mate provides a mechanism that helps product owners and agile teams to implement a clear method for prioritizing and selecting work that needs to be completed.

Project stakeholders who manage the backlog can put the stories they want the team to implement next into the planbox section. (Organizations should agree on the maximum number of stories allowed in the planbox.)

Teams can access the planbox section of all connected projects in a unified view, and they can pull stories from the planbox to their boards. This tool allows teams to implement a pull-system instead of having business stakeholders to push work directly to the team's board. This is to avoid weak prioritization and heavy overload of the team that could happen when decisions of the workload are made by business stakeholders.

Import Boards from Trello to Scrum Mate

Thu, 19 Jan 2017 00:00:00 GMT

Import Boards from Trello to Scrum Mate

Trello is a great productivity software, and an etalon for many board based project management tools. Since Trello is a universal task management application, it has many limitations when used by Scrum and Kanban teams. Scrum Mate offers an easy way to import your boards from Trello to Scrum Mate.

Why import Trello boards to Scrum Mate?

Scrum Mate is an agile management application built for serious agile teams. Our goal is to create a professional agile tool that is so easy to use as Trello, but provides all the essential features professional agile teams require.

Manage user stories in a dedicated product backlog.
Organize user stories into epics and themes.
Estimate user stories in story points, track tasks in remaining work hours.
Plan, execute and evaluate Scrum sprints.
Organize multiple teams and boards into a single project.
Track progress of teams and projects.
Track work hours.

Import Trello boards to Scrum Mate

Moving your project from Trello to Scrum Mate is easy. Simply follow these simple steps.

Click 'New Project' on your home screen
Select 'Import boards from Trello' panel
Allow Scrum Mate to use your Trello account. Scrum Mate will use your account only once, to import your boards.
Select boards, you want to import to Scrum Mate. (At least one board must be selected.) Click the ‘Next’ button.
Select the Trello users you want to invite to your new projects. If the user does not exist in Scrum Mate yet, an invitation email will be sent to the email address you specify. Enter the email address for all selected Trello users. These email addresses will be used to associate Trello members with existing Scrum Mate users or to invite new users into Scrum Mate.
Define the name of your new project.
Click 'Create and import' button. Done!

The import process may take some time. You can close the import popup window. The project will be created once the import process successfully finished.

The difference between task and user story

Tue, 20 Sep 2016 00:00:00 GMT

The difference between task and user story

The key to productive work is not working on more tasks, but selecting the right ones. The question is, how do we recognize the most appropriate tasks? Let's have a look at how we can achieve this.

Understand the outcome first

The best task to work on is the one that provides the most outcome for our customers or end users. The value of the task comes from the outcome the task contributes to. The first step is to identify the outcome and forget the task. In agile development it is common to use user stories and user voice format: As a , I want so that . You can learn more on user stories here: https://www.mountaingoatsoftware.com/agile/user-stories User stories help us focus on the outcome. Have a look at an example, let's say this article. It'd be easy to say that our goal is simple: to write this article. But, we want something better. Let's think about it a little, how could we address the outcome we want to deliver. How will this article create value? The value of this article will only be realized if readers understand and try this method in practice. So, let's write down our user story.

As a website visitor, I understand the value of outcome-driven task selection and will try it, so that I'll be more efficient in the future.

Tasks are secondary

Tasks are activities we need to perform in order to deliver user stories (outcomes). The point is that the more tasks we accomplish – and the more time we spend with those tasks – the more we invest in a user story. Although accomplishing tasks may make us feel like we're progressing, doing it randomly may actually increase our costs without increasing the value we create. This is very important! Tasks alone are not valuable, they're just costs. Only user stories that we deliver to the customer – the outcome – represent value.

How to make a difference between task and user story?

Answer this question: if I only finish this work, will it deliver value to my customers? We need to know who our customers are, in order to answer this question. In the case of this article, our customer is you, our valued reader. Our goal at Scrum Mate is to make your work more efficient. The value will be created only if you change the way you think about tasks and try this method. Does it create any value that I wrote this article and I have it on my notebook? Definitely not, until I deliver it to our readers. So writing an article is not a story, it's a task. I can spend quite some time writing this article without creating any value. Value will be created when the first reader decides to at least consider this approach. There are plenty of other activities I (or someone else) need to perform in order to deliver value.

I want the article to be grammatically correct and easy to read, so I need someone who will proofread it.
Illustrations will make the article easier to read, so I need to draw illustrations and insert them into the article.
I want this article to be read by people, so I need to publish it. Then I'll need to promote it to help spread the idea.
I also want to measure how this article performed, so I need to set up goals in Google Analytics and check reports 2 days and 2 weeks after the article has been published.

The user story describes the outcome of the work, tasks define actions to take Once we've noticed that we have very similar tasks to perform within each user story, then we've identified a workflow.

Workflow : a series of common tasks

Once we've identified common tasks to perform, we won't need to plan those tasks upfront anymore. To help us with workflows, we have a very powerful tool: Boards. All we need to do is to construct a board with columns, where each column represents a status of the user story we're working on. The status can tell us what tasks need to be done next. Here is an example for a publication workflow.

Selected: we want to work on this idea in the near future
Brainstorm: we're generating ideas. The story can leave this column once we have enough ideas to work on.
Write the post
Proofread
Publish
Analyze blog performance and gather insights
Completed

This is the workflow we've constructed. Once we have our board, there is nothing else for us to do other than put all user stories into their appropriate column on the board. This gives us an overview of all active user stories. The columns of the board represent the common tasks we need to perform to deliver a user story There will be other tasks than those that are represented by the columns. For example, our proofreader might advise us to rewrite some part of the article. So, we will need to create a task to accomplish that goal. In the meantime, the user story will be stuck in the “Proofread” column. It's better not to move user stories backwards on the board, and in the following chapters we will discuss why.

Don't work on too many stories at once!

It's very important to limit the number of user stories in progress. At first sight, it might look like a good idea to start a new story and enjoy the feeling that so much stuff is moving forward. But this feeling will cost us a lot. The more stories we are working on, the more time we invest into work that won't produce value in the near future. This is like building a big inventory of unfinished work.

Work can go sour!

Building a big inventory of unfinished user stories can seriously harm our productivity. Work can easily lose its virtue. There can be many reasons for that, but here are a few of them:

The delivery of the value has taken so much time, that customer expectations have changed and they don't need it anymore. So, the time invested in creating something has been wasted or has lost its value.
The person who started the work has been directed to another story or left the company. The new person who takes the job has to learn the context of the work from scratch.
The customer still needs the result of our work, but their priorities have changed and they wish we would have worked on something else instead. There will be a cost of delay.

If we want to maximize the value of our work, we need to work on as few stories as possible. The fewer stories we're working on at a time, the more power we can concentrate on them, so the faster we deliver value. In an ideal world, our team would work on one user story at a time until we deliver it to our customer. In lean manufacturing this concept is called the one-piece-flow and it is at the heart of the famous, hyper-efficient Toyota production system.

Focus your attention on the end of the board

In lean production system there is a concept called pull-system. The pull-system focuses our attention on the last uncompleted item in the process and spurs us to move it forward and free up a slot for a new item. We can only start a new item if there is a free slot for it on the board. If we put all user stories we're working on onto the board, we can easily implement a pull-system. Just follow this simple rule. If someone in the team has free capacity, they should choose a task from the last uncompleted user story on the board. If there are no more tasks available in the last user story, take the furthest one to the right and work on a task from that story. Pull-system: work on the very last uncompleted user story If we follow this simple rule, we end up on working on fewer stories, delivering them faster and reducing the risk of work going sour.

There should be no task without a story

From now we should not think in tasks. We should focus on user stories (valuable pieces of work). Tasks should exist only to help us move the story forward on the board. If someone suggests we start working on a task, we should ask: what exactly is the value this task contributes? Is that value already identified and represented on the board as a user story? If so, is it the last user story we could work on? If not, are we really sure that we need to change our priorities and invest our time working on a story that is not on the right side of the board? Are we aware that we will increase our inventory by doing that?

Make problems visible

If we want to work with a low inventory, we need to resolve issues as quickly as possible. Blocking issues will increase the number of user stories in progress. This is why. If we can't work on a user story because there is an issue that blocks us, we have two choices: stay idle, or choose another task to work on. Staying idle is not very efficient. Starting to work on another user story on the board is OK, but it's not optimal. The optimal task to work on is a task on the very last uncompleted user story. If an issue blocks me from working on my optimal task, then I need someone who can resolve that issue. My job here is to make it explicitly visible that there is an issue that blocks me. Resolving the issue is a task. A very important task. Blocked user stories need priority If there is a blocking issue on any of the stories, our next task should be to resolve that issue.

How to put it into practice?

We said at the beginning of this article that we will consider this article valuable if our readers try to apply this method. Now it's time to summarize the step-by-step guide on implementing the new workflow.

List all tasks you are about to work on in the near future.
Identify the outcome this work contributes to. Try to draw up the value, and name the person who will benefit from this value. Draw up how the outcome will create a value or benefit for that person. Formulate a user story for each outcome.
Now assign each task to a user story. If everything goes well, we will see that many of our tasks belongs to the same story.
Create a board with columns that represent the common statuses of your workflow.
Now focus on user stories. Put all stories in the appropriate column based on their status. If you have more stories in one column, put the most important one at the top of the column.
Take the top user story from the last column and perform all tasks needed in order to move it forward. Repeat until the story is completed.

If you're working in a team, then you can perform a daily synchronization meeting where team members can discuss and select upcoming tasks. You can use our Scrum Mate agile management tool to help you succeed with this process.

Velocity report in Scrum Mate

Wed, 06 Jan 2016 00:00:00 GMT

Velocity report in Scrum Mate

Since Scrum Mate doesn’t restrict you to choose between Scrum or Kanban, the velocity report combines the Scrum Sprint Velocity and Kanban throughput concept. This is the Delivery rate report. The delivery rate report shows your projects average weekly delivery rate measured in story points. This is the weekly throughput of your project.

The last bar shows you the amount of story points delivered in the last 7 days from current time
The line chart shows you the average delivery rate of the past 4 weeks (this is adjustable)

Velocity report in Scrum Mate The report counts every story you delivered from boards, or from the backlog.

Underperforming Scrum Team?

Tue, 01 Sep 2015 00:00:00 GMT

Underperforming Scrum Team?

A method to improve an underperforming scrum team

Many teams suffer from leaving some unfinished user stories at the end of a Sprint. Why does it happen so often, even when the team has made a conservative commitment? Most often, the root cause of this problem is the fragmentation of our efforts into too many user stories. Applying Lean principles can help an underperforming Scrum Team to focus team efforts into fewer work items so they will start less and finish more at the end of the Sprint. Here we have some concepts that can greatly improve the ratio of successful Scrum Sprints.

Achievement vs. activity – make a clear distinction

One of the basic pillars of Lean is to identify value. Teams should be clear about when they have created value to their customers. This is what I call an achievement. User stories in agile development are great to use as units of achievements.

User story: an achievement that creates value

A user story represents an achievement that creates value for the customer. Most teams create value through a well defined work flow. In Scrum Mate, we represent this work flow on a user story board.

A task represents an activity

Scrum Mate makes a clear distinction between user stories and tasks. User stories are valuable achievements, delivered through a series of work flow steps. On the other hand, tasks are activities that need to get done in order to move a story forward on the board. While a user story is accomplished by the joint effort of the entire team, a task is often completed by a single person or a pair of team members. Whenever something needs to get done in order to push the user story forward on the board, the Team creates a task. Tasks help the Team define clear actions in an often uncertain process of delivering a user story. While user stories are known and selected in Sprint planning, tasks are often recognized during the Sprint on the fly, as the Team makes progress in understanding the problem they need to solve.

Story board for process, task board for activities

Based on the idea of separating value creation process from activity tracking, Scrum Mate provides different boards for user stories and tasks. The value creation process may consist of several workflow steps (columns) based on the specific needs of the team. The task board however is simple. An activity is either waiting to do, doing or done. Complicating the task board further would cause unnecessary confusion. If the video in the example above can’t be published because there is a mistyping in the demo user story, then we need to perform new, unplanned activities like recording a certain part again and replacing the old screens with the new ones.

Eliminating waste

The most common obstacle to achieving a Sprint Goal is the great number of user stories in progress. This should be on a top of a Scrum Master’s list to check the root causes of an underperforming Scrum Team. In Lean Production it’s called inventory. From the moment we start working on a user story, we are producing an inventory of work until the story is delivered to the customer. The larger the inventory – e.g. the more user stories in progress – the slower the value creation process. This much work in progress can lead to a situation where at the end of the Sprint we have a lot of ”almost done” user stories but only a few ”completed”. Or even none of the user stories are completed…

One piece flow

We are producing the lowest amount of inventory if we are implementing a one-piece flow. In a one-piece flow there is exactly one user story in progress. It’s rarely possible in reality, but it’s a good goal to pursue. On the user story board we can clearly see the inventory of our process. It’s great practice to focus on the one-piece flow during daily scrum meetings. We can change the routine of the Daily Scrum Meeting by starting with the last uncompleted user story on the board and asking the question: what we need to do in order to move this story to the next column? Once we have identified the tasks, Team members can volunteer to complete them. You can read more about Lean Daily Scrum Meetings by reading this article.

Highlight bottlenecks

Some stages in the workflow are more likely to get overloaded. Too many user stories in the Testing and Bug-fixing column are good indicators that the downstream process is suffering from a quality issue. It’s a good idea to set limits on work in progress for these sensitive columns. Once a column exceeds its work in progress limit, the Team needs to stop immediately and investigate the root-cause of the problem and resolve it as soon as possible.

Eliminate context switch

Context switching is a waste on the individual level. If someone has a lot of tasks in progress, then he needs to switch between them frequently. Too many context switches can easily reduce productive time by half or even more. While it’s easy to discover excess work in progress, it’s much harder to uncover context switching. This is where separating tasks from user stories pays off again. On the Scrum Mate task board you can easily check tasks in progress for each Team member by clicking on their profile photo on the top right corner.

Maintain the flow

If a user story gets stuck in the process because of a problem, it’s important to inform everyone in the Team that there is a serious issue to solve. In Scrum Mate we can create tasks that represent a ”blocker” issue. Solving an issue is a task in Scrum Mate.