Spend some time with any Scrum team and you’re bound to hear jargon such as sprint, daily, or backlog. That said, these terms are more than just buzzwords: they are essential components of the Scrum framework.

Today, we’ll be focusing on one of those concepts: the backlog management. In fact, we’ll go one step further and talk about two backlogs, since Scrum teams work with both a product backlog and a sprint backlog. But, what is the difference between the two? What is a backlog in the first place? And, if it’s so important, what are some tips for successful backlog management? We’ll try to answer all these questions in this article.

What is a backlog?

In short, a backlog is a list of the tasks a Scrum team needs to complete to achieve their goal. It can act as a roadmap for the team by helping them get organized and plan their steps. To do this, all the items in a backlog are prioritized and should include an informative description.

As for exactly what tasks are to be included in a backlog, that will depend on what type of backlog it is. As we mentioned before, Scrum teams work with two types of backlogs during their app development process: a product backlog and a sprint backlog. Both of them include tasks that the team needs to follow to improve their product, but how those tasks are selected and added to the backlog will depend on each case.

Product backlog vs. Sprint backlog

To understand the difference between a product backlog and a sprint backlog, you first need to understand another core Scrum concept: the sprint.

Put simply, sprints are iterations that span for a given time or, as the 2020 Scrum Guide puts it, “they are fixed length events of one month or less to create consistency”. When a Scrum team takes on a project, they start with a product backlog containing tasks they need to complete to meet their product’s requirements. As they start each sprint, they select tasks from the product backlog to work on during this time. Those tasks make up the sprint backlog.

Because of this, it is often said that the sprint backlog represents the present—as it acts as a list of tasks that the development team is currently working on—, while the product backlog represents the future—as the tasks it includes will be worked on during a future sprint.

At the same time, because of their nature, ownership of each backlog belongs to different members of the Scrum team. While developers are solely accountable for each sprint backlog, product owners play a bigger role when it comes to refining and maintaining the product backlog.

5 tips for successful backlog management

As you can see, regardless of which kind, backlogs are crucial for organizing Scrum teams during the whole app development process. Unfortunately, though, as time passes and a project grows, they can become increasingly difficult to manage. With that in mind, here are some tips for healthy and successful backlog management:

Keep your backlogs visible

You’ve probably heard the expression “out of sight, out of mind”, and it certainly applies here. If you and your team rarely take a look at the tasks that make up your backlog, it will be easy to forget them and stray from your plan. If you work in an office, consider getting a physical representation of your backlog (maybe in the form of sticky notes) to post on a wall. If you are working in a remote team, make sure your backlog is somewhere everyone in your team can easily access, which brings us to our next tip.

Use the right tools for backlog management

There’s no need to reinvent the wheel and, fortunately, there are plenty of tools out there for proper backlog management. We’ve discussed some of the most popular ones—Trello and Jira—in a previous article, but there are plenty more options out there. Whichever tool you choose, make sure it lets you store all the necessary information and displays it in a clear and easily accessible way, since you and your team will be revisiting your backlogs on a daily basis.

Prioritization is king

A well-prioritized backlog is a healthy backlog. Make sure the team knows what priority each task has. In the case of the product backlog, this will help them decide which tasks should be moved to the sprint backlog at the start of a sprint. At the same time, in the case of the sprint backlog, it will help developers organize their work as they go along. Moreover, don’t forget that priorities can change, so keep this aspect of your backlog updated. In fact, as we are about to see, updating is key to successful backlog management.

Backlogs aren’t set in stone

You might be tempted to think that, once app development on a certain backlog has started, it can no longer be changed. However, the truth is quite the opposite: both product backlogs and sprint backlogs are meant to be constantly refined and updated. After all, “responding to change over following a plan” is one of the four core values of agile methodologies. Fail to keep items updated and organized, and you’ll soon find yourself trapped in a backlog management nightmare.

Get the whole team involved in backlog management

Scrum is a team sport, and this certainly extends to backlogs. The more you involve the whole team in drafting both backlogs, the better understanding they will have of what it includes, which will make work easier down the road. At the same time, more eyes will be able to better spot opportunities for improvement, thereby streamlining your backlog management process.

Final thoughts on backlog management

Both product backlogs and sprint backlogs are essential for any Scrum team. They help guide the app development process, so it is crucial that they are updated and well organized. Hopefully, this article has helped you get a better idea of what each backlog entails and how to step up your backlog management game.

The post Successful backlog management appeared first on asap developers.

Part of creating an excellent development project is picking the right tools. Moreover, as technology advances at a fast pace, you will need to keep up with the various new tools that reach the markets, as well as the latest updates of existing ones. In this article, we’ll give you an overview of the best development tools for 2021. Whether you are working on mobile, web or desktop development, we’ll look into different areas and include code and text editors, frameworks, integrated development environments (IDEs), and control systems.

Code and text editors: best development tools

Atom

Atom was published in 2014 by GitHub. This free open-source text editor is fully customizable using JavaScript, HTML and CSS: you can add countless packages and choose from a variety of themes, among many other features. Atom includes a built-in package manager, smart auto-completion, and a file system browser. It also supports cross-platform editing and you can use the Electron framework to build cross-platform apps with Atom. This text editor is friendly, hackable and helps you code faster.

Sublime Text

This text editor offers both free and paid versions. You can take Sublime for a trial run, but are required to buy a license for continued use which currently costs $80. Its features include multiple selections, full customization, split editing and an excellent package and API ecosystem. Sublime Text also supports cross-platform development and is available for Mac, Windows and Linux.

Visual Studio Code

Visual Studio Code was developed by Microsoft and works in Windows, Linux and macOS platforms. This free source code editor is great for responsive design and includes excellent debugging and troubleshooting features. Moreover, it provides intelligent code completion, built-in Git commands and code recovery. Visual Studio Code is fully customizable, offering a wide variety of extensions you can access from its Marketplace.

Frameworks: best development tools

Django

Django is an open-source Python web framework which has been gaining a lot of popularity recently. It has been used extensively by big shots such as Mozilla, Spotify and Instagram. Django was built by experienced developers and aims at using automation wherever possible. This helps speed up web development and gives developers the chance to focus on the important stuff. Django is fast, secure, portable, versatile and highly-scalable. Other features include a default admin panel, various SEO tools, a vast number of libraries and an excellent community. You can learn more about Django here.

Xamarin

This open-source framework is owned by Microsoft and works on the “write once, run anywhere” (WORA) model. Xamarin uses C# as a single language (which means you don’t need to learn Swift or Java) and harnesses the power of the .NET platform to build native apps for Android, iOS and Windows.
This framework can be tested in multiple devices through cloud services and includes native API access and native UI support. Xamarin also lets you add Objective-C, Java and C++ libraries to its already considerable collection of class libraries.

Angular.js

Angular.js is an open-source framework launched by Google in 2010 and rereleased after a significant overhaul in 2016.
Angular.js is used to create single-page web apps and is known for being fully expandable and extremely secure. Other features include DOM sanitization and UI view templates. Angular.js is also cross-platform (used for PWAs, native and desktop apps) and lets you create accessible applications.

React.js

React.js is really a JavaScript library used to build UI interfaces on the web. It was launched in 2013 by Jordan Walke and a group of Facebook engineers. React.js’s launch was groundbreaking as it introduced the Virtual DOM, improving user experience and performance. This library is used for front-end web development, but it is also often paired with Electron for desktop apps and with Node.js for backend development. It is also the heart of React Native, a popular framework for mobile app development.
The React.js library is component-based, declarative and open-source, and its features include SEO support, reusable components, one-way data flow, easy integration and simple syntax.
React.js is one of the most popular JavaScript frontend frameworks, as evidenced by Stack Overflow’s 2020 survey and The State of JavaScript.

Bootstrap

This open-source CSS framework, launched in 2011, is aimed at mobile-first development. Bootstrap is customizable, includes a variety of built-in components and plugins and a responsive grid system. This framework is also great for fast prototyping, it’s consistent and easy to use, and there is extensive documentation available on it. Moreover, Bootstrap is compatible with the latest versions of all major browsers and is definitely a great tool when it comes to responsive development.

IDEs: best development tools

AWS Cloud9

Cloud9 is a cloud-based IDE that supports a variety of programming languages, including C, Python, JavaScript and PHP. It was launched in 2010 and acquired by Amazon in 2016, when it became part of Amazon Web Services (AWS). This web-based platform enables you to script, run and debug your code in the cloud. Some of its most relevant features include code completion suggestions, file dragging and debugging. With Cloud9, you can share your environment with other teammates working on the same project, which makes it an excellent tool for remote teams.

NetBeans

This open-source and free IDE was written in Java and launched in 1997, with a long list of new versions released since then. NetBeans is used to develop web, mobile and desktop apps using C/C++, PHP, JavaScript and Java, among other programming languages. This IDE supports cross-platform development and works in any operating system (including Windows, Linux and macOS). Some of its features include smart code editing, quick user interface development, a powerful GUI builder and an easy and efficient management process. NetBeans also excels at helping developers write bug-free code.

Control systems: best development tools

GitHub

GitHub is an outstanding collaboration tool when it comes to development. It was founded in 2008 and focuses on code review and code management. GitHub offers free development plans, as well as extra benefits for premium users, with varying prices for individuals and companies. This source control platform has over 56 million users worldwide and over 100 million repositories. GitHub lets you host your code for free, collaborate with your team through the cloud, create instant work environments with Codespaces and automate your workflow with GitHub Actions, among other features. GitHub’s project management features are highly praised by many.

Atlassian Bitbucket

Bitbucket is a web-based control system that facilitates collaboration between dev teams. Launched by Atlassian in 2008, it, of course, integrates very well with JIRA. Similarly to GitHub, it works as a repository for source code and development projects. Its features include flexible deployment models, free unlimited private repositories and built-in continuous delivery. Bitbucket supports services for code search, integrations and smart mirroring, among others. The free version of Bitbucket allows up to 5 users, and there are also standard and premium versions that offer extra benefits such as unlimited users, larger file storage capabilities and two-step verification.

Final thoughts on the best development tools for 2021

The development world has an endless supply of tools available to meet the needs of each team. If you are lost among all the options, thinking about the type of project you are working on, your budget and your team’s specific skills will help you narrow it down. We also hope this article has helped you by giving you an overview of the best development tools for 2021.

The post Best development tools for 2021 appeared first on asap developers.

In this article, we’ll be comparing JavaScript vs TypeScript by going over the various aspects and attributes they offer.

TypeScript’s popularity is increasing with each coming year. According to State Of Js, most developers have either used this language and liked it or have heard about it and want to start using it. Moreover, famous frameworks like Angular or React use or have pre-configured templates that include TypeScript on their initial project. However, not everyone uses this language and there’s still a large community that uses JavaScript.

Documentation

When using third-party libraries or packages, you will probably need to read some documentation from sources such as npm or GitHub. This is definitely the case with JavaScript.

However, when using TypeScript and VS Code, you can see the documentation right in your IDE:

Let’s see an example using node and express.

Link: script

The cool thing about this is that if you don’t know what the send function does, you can just place the cursor on it and get some information:

Also, if you want to know more about what the variable res can do, you can just hit Ctrl + . or Cmd + . :

Moreover, when working on a project with teammates, you don’t need a lot of documentation if you are using TypeScript. Using good function/variable names and setting the types to each variable/function, should be enough to express the responsibility of that variable/function. Of course, there are exceptions in which a function is too complicated and a comment would make it easier to understand, but this should be an exception. It’s always best to avoid commented code.

Modifying a function: JavaScript Vs TypeScript

Let’s see an example of a sum function in JavaScript.

Link: script
The result of executing the code is:

As you can see, JavaScript lets you use the same sum function for both strings and integers, which could be an advantage, as you can use the same function for multiple types and get a result without checking the types of the parameters.

However, let’s modify our function to add the first elements of two arrays, like this:

Link: script

The result of executing this code is:

As you can see, it seems to work well with strings, but we get a NaN with integers because we cannot access a specific index of an integer.

The example includes very simple code, but if we were dealing with real software, where you have to modify a function that impacts or is used by a lot of other functions or other external services, this could become a problem. You may need to know exactly what the parameters are, and what they represent, and what the function you’re modifying is returning. 

JavaScript gives you the freedom to manage the code however you like, but if you are returning an array where you’re meant to return a string, other functions or services using your function are likely to crash or you may even get an unexpected result.

On TypeScript, the same function would look like this:

Link: script

As you can see, we are specifying the type for each parameter, which allows us to know that we are receiving a number as a parameter and returning a number as well.

This means that if you call the add function with a string, as in the example below, you will get an error:

If you are using VS Code, you can see this before you even run the code:

The same happens if you return something other than a number:

Another example would be to add or remove parameters from a shared function.

Let’s assume we have the following structure:

src
|- index.js
|- utils.js

In utils.js we have a function that only concatenates two strings with a space between them:

Link: script

And in index.js we call this function like this:

Link: script

If in the future we need to modify this function and add more parameters (in our example, we need to concatenate 3 strings instead of 2), in JavaScript we would modify concatStrings like this:

Link: script
If we do not modify our code on index.js to pass another parameter to our function, we will not notice any errors until we run the code:

Here we are only using our function in one part of the code, but if you were using this code in multiple locations of a large project, you would not get an error anywhere because it would not crash. Instead, you would get an unexpected behavior because, somewhere, you would be getting an undefined where a different result was expected.

Let’s see what happens when we use TypeScript. The structure would be the same, but with ts extensions:

src
|- index.ts
|- utils.ts

The utils.ts file would look like this:

Link: script

And the index.ts file would look like this:

Link: script

Here, if you failed to provide all parameters, the interpreter would tell you that something is wrong:

And if you ran the code, you would get the following error:

This is one of the advantages of TypeScript because we know exactly what went wrong and where. Therefore, other functions won’t get an expected result and work as if nothing had happened.

Missing imports

Let’s follow the same structure as the example above, but adding the add function to the utils.ts file, and using it on the index.ts file:

Link: script

Link: script

If you are using VS Code, you would get some warnings on the index.ts file:

As you can see, we need to import these functions.

Using TypeScript and VS Code, we can import all the functions that are being used by tapping Ctrl + . or CMD + . and selecting “Add all missing imports”:

Unfortunately, this feature is not available in JavaScript.

Using interfaces: JavaScript vs TypeScript

We can get the best out of interfaces using TypeScript.

You can create an interface like this:

Link: script

If you have a function that receives a User as an argument, you could access its properties without looking at its file:

Although JavaScript has grown as an OOP language in recent versions, as of today, it does not have a native way of implementing interfaces.

Summary

Now that we’ve looked at the main features, here is a summary of the pros and cons for each language:

• JavaScript gives you the “freedom” to use your code by sharing functions and variables without specifying a type, and passing anything you want without compiling errors. However, remember that you will probably work with other people, who may not understand your code, and comments could make it ugly. 
• TypeScript gives a better understanding of your code by introducing typing, so others (teammates or clients) can use it with the confidence of knowing what it does and what it needs.
• As JavaScript is an interpreted language, you won’t get the errors until you run the code. TypeScript allows you to find those errors sooner.
• On TypeScript, you can use interfaces to specify your own “types” and make the code cleaner and understandable.
• TypeScript allows you to go through documentation more easily and faster, as well as make your own documentation a lot simpler.
• TypeScript needs to transpile the code to JavaScript (as browsers only understand javascript), so this makes it a bit slower.
• TypeScript would take more time to configure and code than JavaScript as you need to specify types and probably have a different structure. However, you will save this time on finding bugs and errors.

Final thoughts on JavaScript vs TypeScript

Both languages have their pros and cons and their extra features. Choosing between the two will come down to your team’s needs or even the needs of each specific project. We hope this article has given you enough information to make the right choice.

The post JavaScript Vs TypeScript appeared first on asap developers.

In a previous article, we discussed agile methodologies and their benefits. We mentioned there are two core agile methods: Scrum and Kanban. In short, Scrum is the preferred choice for cross-functional teams working on a product with tasks that can be divided into more than one iteration, while Kanban consists of an extensive requirement list where tasks are tracked according to their stage in the process. In this article, we’ll go into detail and explain what Scrum and Kanban entail and the main differences between Scrum vs Kanban.

What is agile?

To recap, agile is a set of principles and ideals that give way to specific development methodologies. These methodologies are based on close collaboration between developers and stakeholders, which is why early and frequent deliveries, continuous improvement and great adaptability to change are part of its foundations. Agile methodologies take into account that the ability to respond and adapt is vital to succeed, especially in a world where technology and trends are continuously developing and shifting. Scrum and Kanban are two agile methods or processes that help implement the agile project management approach in different ways.

Scrum

What is Scrum?

Scrum is a product development framework that aims at delivering value in the least amount of time possible. It places an emphasis on teamwork, as well as on dividing progress into relatively small increments. In Scrum, this progress is divided into iterations called “sprints” that usually last two to four weeks. Key features and goals are defined before each sprint to complete a specific set of tasks or a product increment. This means that, by the end of each sprint, a Scrum team should have completed a new feature of the product.

When should you use it?

Due to its nature, Scrum works best in cross-functional teams working on projects that can be easily split into clearly-defined increments. This agile methodology is also quite useful in cases where requirements may change throughout the project or where not all details are available from the get-go.

How does it work?

Scrum relies heavily on communication and entails various meetings that help with the various parts of the process. To begin with, there are sprint planning meetings at the start of each sprint to establish goals. Then, there are daily meetings during each sprint called daily scrums in which the team goes over the progress so far, as well as any problems that may arise. Finally, at the end of each sprint, a retrospective meeting is held to reflect on the sprint process and focus on what went well and what needs work for the next iteration.

Moreover, Scrum includes three clearly defined roles that help everything go over smoothly: the product owner, the scrum master and the development team. The product owner is in charge of managing the product backlog, prioritizing the work to be done. The scrum master makes sure the team follows agile values and principles and the development team is made up of the people in charge of delivering the tasks included in each sprint.

Kanban

What is Kanban?

Kanban works as a visual system that helps a development team organize its work. It is basically a to-do list that includes all requirements, which are tracked according to their stage in the process (to-do, doing and done). What matters in the Kanban method is not so much delivering a specific item in a set amount of time, but the priority of the task at hand.

When should you use it?

Kanban is particularly useful for specialized teams working on projects that are highly unpredictable. If many changes are expected along the way, Kanban allows teams to easily change priorities and focus on the more urgent tasks. As Kanban tasks or features don’t have a fixed delivery time, they can be postponed if the client requests a different one to be released first.

How does it work?

Due to its adaptability, there is no set process for Kanban, but there are four key principles or practices. The first is visualization: Kanban uses a board that helps visualize the work that is being done. The board can be customized as needed but has three core categories: to do, doing and done. The second practice is limiting the work in progress to improve workflow and quality, as well as to carry out more frequent deliveries. Third comes flow management, aimed at maximizing value delivery, minimizing lead times and being as predictable as possible. Finally, Kanban revolves around the continuous improvement of the team’s development process.

Unlike Scrum, there are no specific roles in this approach. Teams usually use the ones that they have already set and adapt them if they consider it necessary.

Scrum vs Kanban: Main differences

Now that we have a clear idea of what each of these concepts entails, let’s take a look at their main features side by side:

Final thoughts on Scrum vs Kanban

As you can see, whether Scrum or Kanban is the best choice for you will depend on the structure of your team and the requirements of the project you are working on. It is important to know the differences and what each one involves to make sure they are the right fit for your project and avoid any issues. You might even find that a hybrid model is more appropriate and enjoy the best of both worlds. We hope this Scrum vs Kanban has given you some insight into the practical world of agile methodologies and some clarity on what Scrum and Kanban really mean.

The post Scrum vs Kanban appeared first on asap developers.

As we’ve mentioned in previous articles, agile methodologies are extremely useful when applied to development teams. They are a great tool to increase flexibility and provide a high-quality product with an early delivery. You should also know that agile methodologies are not just applied during a specific iteration or sprint. A big part of agile is reflecting on what you’ve done well and on what you can improve beyond a specific project or iteration. This is where the agile retrospective comes in.

What is an agile retrospective?

An agile retrospective is a meeting that tends to take place at the end of each sprint during a project’s development, as well as after the project has been completed. In this meeting, the team reflects on what happened during that period of time. They focus on the positive and negative aspects and establish clear goals to improve or correct any issues they might have come across without passing judgment or placing blame. The goal is to learn from the process and establish clear steps to improve in the future.

How can I organize an agile retrospective?

Retrospectives can vary according to your team’s needs and the project you’re working on, and there is no established winning formula. However, you will need three basic things: a set amount of time (both to prepare and carry out the retrospective), someone to facilitate the meeting (usually the scrum master, if you have one) and a plan on how it will be structured. It is also advisable to include some materials like a whiteboard, markers and sticky notes (to write down everyone’s thoughts) as well as a timer (to make sure everyone is focused and you don’t run out of time). If you are part of a remote team, there are also ways to carry out retrospectives online with tools such as RemoteRetro and Parabol.

When it comes to structure, a classic retrospective will have you follow these basic steps:

1. Take a few minutes before the meeting to prepare the space (whether physical or virtual) with the materials you’ve decided to use.
2. Once everyone is there, set the stage and clearly explain how the agile retrospective will work.
3. Have everyone take a few minutes to write down what they think went well during development and then discuss each point.
4. Do the same as in the previous step, but focusing on what needs improvement.
5. Finally, work to establish concrete and actionable ideas on how to improve what went wrong and carry on actions that have a positive impact. Each of these ideas should have a clear owner and due date. You can divide people into teams so they can discuss their thoughts and then present them to everyone else.

What makes a great agile retrospective? 

Like we’ve mentioned, retrospectives can take on many shapes. But, regardless of which one you choose, there are some things you can do to make sure yours is successful.

1. Plan ahead and outline a clear structure to follow. You usually don’t have too much time to spare for a agile retrospective and, even if you do, it might be counterproductive to have an exceedingly long one. A structured plan will help keep everyone on track and get the most out of the meeting. Of course, you should also allow time for people to stray or plans to fall through. Just remember to try to lead everyone back to the topic at hand.
2. Create a safe space and encourage open communication. Make sure everyone feels comfortable enough to be honest and voice their opinions, otherwise, the retrospective won’t really work.
3. Always include the positives. We sometimes tend to give more weight to what needs work, but focusing on what we’ve done well is just as important. Doing so will not only help team morale but will also make it easier to keep applying what worked down the road.
4. Schedule them regularly. Retrospectives work best when done periodically and, even if you don’t think you and your team have much to discuss after a specific sprint, you might be surprised after having the meeting.
5. Don’t get frustrated if they don’t go well. You may have spent a long time planning the perfect retrospective and when it’s time to put it into action, everything falls apart. Try not to stress and instead focus on what to improve. You can even have a retrospective on retrospectives if this is a running issue.

Some agile retrospective ideas

Variety is the spice of life and bringing fresh ideas to the table will help keep your team motivated. Here are some you can use:

• Checking in and out. If you feel you might have some extra time, you can check-in and out at the beginning and end of your meeting with a simple 1-2 minute task. This could entail having everyone draw their feelings or write a word to check their general thoughts about the sprint. You could also ask your team to write a note to themselves or grade the agile retrospective at the end of the meeting.
• Mixing it up. The classic “What went well?/What needs improvement?” can have dozens of variations and twists. You can also add categories instead of merely sticking to the pros and the cons. Some examples are using headlines like “learned, lacked, loved,” “happy, med, sad” or “start, stop, continue.” Using these variations gives you the possibility to add nuances instead of focusing merely on what went right and wrong while making things a bit more entertaining.
• Themed retrospectives. You can take your imagination a step further and give a specific theme to your retrospective based on what your team likes. You can get creative with spells and potions from Harry Potter or Game of Thrones locations for your categories, or even do a variation of the hero’s journey based on The Lord of the Rings.
• Dot voting. Though not nearly as much fun, dot voting is a good strategy to prioritize any issues that may come up during an agile retrospective, particularly if the team has come up with a lot of different points. You can give each participant a maximum number of points (from 3 to 5 is usually a reasonable amount) which they can use as they see fit. They can even allot all their points to one issue if they think it’s that important. After tallying up the votes, you can go over the top priority issues based on the number of points they’ve received. This is particularly useful when prioritizing your next steps at the end of your retrospective.
• Acknowledgments. Retrospectives are not just a tool to focus on what needs work, so it’s important to use this time to also focus on the positives. Asking your team to take a minute to acknowledge each other’s accomplishments or thank a specific team member for their help may give them a nice boost and help them feel at ease when sharing what’s on their mind.

If you’re looking for more ideas, you can go to Fun Retrospectives or FunRetro where you’ll find quite a few to use as-is or adapt for your team.

Final thoughts

Agile retrospectives are a vital part of agile methodologies. They will set the goals moving forward after each sprint or project and help you and your team become better developers. There is an endless supply of tools to make them productive and entertaining, so be sure to do your research and invest the proper amount of time on them. You should also make sure you leave the meeting with tangible actions to improve in the following sprint and follow up on them.

The post How to run a successful agile retrospective appeared first on asap developers.

Project management tools are essential in any successful agile development team. Luckily, there are plenty of options to help you organize and manage all your development projects, whether for in-house or remote work. Jira and Trello, both powered by Atlassian, are great examples of useful agile tools and are the ones we’ll be focusing on in this Jira vs Trello. So let’s dive right in.

About Atlassian

Based in Australia and founded in 1998, Atlassian launched the first version of Jira in 2002 and later acquired Trello, which was originally launched in 2011. The company currently has offices in 7 countries, has acquired over 150,000 customers and 2,6 million community members. It also has more than 4,000 apps in the marketplace. In addition to Jira and Trello, the company is also behind Bitbucket, Bamboo and Crowd.

Jira

Overview

Over the last few years, Jira has taken the lead among software development tools helping numerous teams. This tool helps you plan, track, release and issue reports on projects. Its biggest benefit is that it is almost plug-and-play, giving you the freedom to choose between a scrum and a kanban board while customizing many of the details. You can also choose a preset workflow or create one that matches your needs more closely. Moreover, Jira also includes plenty of integrations, such as Slack, GitHub and Bitbucket, and over 3000 apps. Some people argue that Jira is not the most user-friendly software, but it does have a great community and plenty of documentation available to help you navigate it.

Jira Plans and Jira pricing

Jira offers different products according to your needs: Jira Software (for planning and tracking), Jira Service Desk (for customer service), Jira Core (for business management) and Jira Ops (for incident management). Our main focus will be on Jira Software, but you can check out the main features of each one through this link.

Jira Software offers two plans: cloud or self-managed.

• Cloud: this plan includes three base options—free, standard and premium. With the free option, you can have up to 10 users, enjoy both kanban and scrum boards, as well as a backlog, reporting, customizable workflows and roadmaps. It also includes apps and integration, 2GB file storage and community support. The standard option starts at $7 per user per month and increases the user limit to 5,000 and the storage limit to 250GB. It also adds Jira support during business hours, advanced permissions, anonymous access and audit logs. Finally, the premium option starts at $14 per month per user and, on top of all the previous features, adds advanced roadmaps and project archiving, among several other benefits. It also provides unlimited storage and 24/7 support. Keep in mind that both the standard and premium options offer a free trial so you can have a taste before making any final decisions.

• Self-managed: this plan offers two options, a one-time payment for the server depending on the number of users (starting at $10 for 10 users) and a per year data center cost (starting at $20,400 for 500 users). The server option includes complete environment control, single-server deployment and a perpetual license with a free year of maintenance. The data center option includes and annual term license and project archiving, and is optimized for AWS or Azure deployment, among other features.

Trello

Overview

Trello is a simpler tool that allows you to create your own kanban board from scratch to meet your specific requirements. You can create boards with as many columns as you like and add cards to each of them, which can be very comprehensive, including plenty of detail. Trello has recently added templates for the paid versions which you can use if you prefer to work or start with a predesigned board.

Trello is available online and as a web or mobile app. It also offers Power-Ups that allow you to add extra features, as well as a wide variety of integrations, such as Google Drive, Slack and Jira. One of Trello’s most prominent features is Butler, which gives you the ability to create automation or command runs to trigger actions on your board.

Trello Plans and Trello pricing

Trello offers three main plans:

• Free: just like Jira, Trello’s basic features can be used for free. This plan includes unlimited personal boards, cards and lists, a 10MB limit per file attachment and up to 10 team boards with 1 Power-Up per board. It also includes simple Butler automation with up to 50 commands per month and 2-factor authentication as a security feature.
• Business class: this plan starts at $9.99 per user per month if you pay annually (or $12.50 if you prefer to do it monthly) and adds a 250MB attachment limit to the previous plan. It also includes priority support, observers and custom and background stickers. Moreover, you’ll be getting unlimited boards, board collections and templates. There are unlimited Power-Ups with this option and over 100+ app integrations, as well as a wider range of Butler options and features with up to 6,000 commands per team. Finally, it also includes several security features, such as advanced admin permissions, deactivating members and domain-restricted invites.
• Enterprise: this last plan is priced based on the number of users, with the per-user cost decreasing the more users you include (meaning that, for example, you’d pay $20.83 per user for 100 users, but $12.92 per user for 1,000 users). In addition to all of the above, it includes unlimited command runs for Butler and even more advanced security features such as power-up administration, organization-wide permissions and attachment restrictions.

Jira vs Trello

As you can probably tell by the previous descriptions, the main difference between these two project management tools is their target audience. Jira is specifically aimed at development teams, while Trello works for pretty much any type of project. Now, let’s see what they have in common and what things set them apart when it comes to specific features.

What brings them together

• Free and paid versions.
• Available as Android and iOS apps as well as on the web.
• GitHub and Bitbucket integrations.
• Cloud-hosting.
• Aimed at both SME and freelancers.
• Task, resource and document management included.

What sets them apart

• Jira offers on-premises hosting (in addition to cloud).
• Jira offers task and issue management.
• Jira includes reporting or charts.
• Trello is limited to kanban boards while Jira includes more adaptable options.
• Trello lets you run sprint retrospectives and meetings.
• Trello gives you the possibility to brainstorm product and development ideas.

Final thoughts on Jira vs Trello

As you can see, both tools have their pros and cons and you can even say they complement each other in some cases. They are both incredibly useful project management options for your development team and offer you different pricing plans and features depending on your team’s needs. We hope this Jira vs Trello helps you figure out which of these tools would work better for your specific situation.

The post Jira vs Trello appeared first on asap developers.

Thanks to technological advances, remote work has been on the rise for the last few years, and with good reason: it has been proven that companies offering the option to work remotely see a 25% decrease in turnover. In the US, there are plenty of companies that are fully remote and most companies work with at least a percentage of remote workers. It is not shocking to hear that a great number of those companies work in the development field. However, there are also difficulties that come with working with a remote development team. This is why, in this article, we’d like to share some tips to help you create the best remote development team possible.

1. Communication with a remote development team

Communication is an essential factor in any team, but especially so when it comes to remote work. In this case, it is better to over-communicate than to risk some details slipping through the cracks. It is also important to provide regular feedback.

2. Take different time zones into account

On the topic of communication, while one of the advantages for remote workers is that they can work from anywhere, there is a clear disadvantage in having members of your team spread through different times zones. You should make sure to schedule regular communications in the time zone that is most beneficial for all members. Make the most of the hours when all team members are working simultaneously.

3. Don’t micromanage

Nobody likes to be micromanaged, but it is an easy trap to fall into when dealing with a remote development team. Make sure you hire people you can trust and show that trust by empowering them instead of double-checking every move they make.

If your company is not fully remote, it might be best to have your lead-talent in-house and have the remote workers be an extension to maximize your junior developer capacity. This way, the in-house senior developers can be in charge of major reviews and testing.

4. Hire the right people for your remote development team

As we’ve mentioned, you need to be able to trust your remote team members. This means you should pick developers with the right set of skills for your project. Remote developers should have excellent communication skills and, if you are going offshore, you should make sure they have the right level of English to avoid any miscommunication.

5. Provide room for growth

Your company culture should include opportunities for continuous learning and growth to keep your team motivated. This could include anything from online courses and workshops to having knowledge-sharing sessions. Having said that, promoting knowledge sharing is also a way to ultimately add to the growth of your product.

6. Define work procedures for your remote development team

You should have clear guidelines from the get-go in all fields, including productivity, teamwork and accountability. This will ensure the whole remote development team has the same expectations and know what needs to be done and how.

You should also set clear tasks and answer any questions that may arise in as much detail as possible. Answer emails promptly and don’t leave anyone hanging as the team will depend on the information they receive from you. Moreover, consider applying agile methodologies and study how to implement them.

7. Find the right collaboration tools

There is a myriad of collaboration tools available for remote teams. You should focus on your remote development team’s needs and figure out which ones will work best in your particular case. However, there are some essentials that you should incorporate, like an email service, a tool to share files, an instant messaging and video conferencing platform, and project management software. There are many options you can choose from, regardless of whether you are looking for an all-in-one solution (such as Hive or BasicOps) or prefer to use different tools (such as Trello or Jira for management, Google Drive for sharing documents and Zoom or Slack for communication).

8. Keep relevant documentation

As we’ve mentioned, it’s important to define work procedures. However, for these procedures to stick, it is important that you document them. In fact, pretty much everything you discuss should be written down. Make sure you are keeping up to date with the appropriate documentation so your remote developers can refer back to it when necessary as well as comment and provide feedback on it.

9. Use alternative methods to get your point across

Although it is very important to keep documentation, a picture is also worth a thousand words. Pictures, videos or screenshots may prove to be a lot more useful than long documents or email chains when it comes to explaining something or trying to make a point to someone on the other side of a screen. Not to mention, it saves a lot of precious time.

10. Build rapport

After-office meetings or casual Fridays are not an option for most remote teams, so you will need to find other ways to build rapport. Building a personal connection means increased trust and morale, as well as making self-organization easier. You should take the time to get to know each remote developer in your team. You should also make sure to schedule regular video conferencing meetings so remote workers can have face-to-face interactions. As a matter of fact, it is even a good idea to include some 1:1 sessions so they can get to know each other. With new members, you can easily break the ice by having them write an intro blog post to introduce themselves to the rest of the team.

11. Build a culture and share company values

Another important factor to consider when creating a remote development team is making sure everyone is aware of and shares the company’s values and culture. This will help remote workers feel as much a part of the team and the company as those working on-site.

Final thoughts on the best remote development team

As you can see, most of the rules that apply to an on-site team also apply to a remote one. The main difference is that you have to put more of an effort into making sure all relevant information is getting across and everyone feels involved. Not interacting face-to-face with everyone on a daily basis makes it harder for a team to succeed. However, there are plenty of tools to help you create the best remote development team possible and work towards an even more successful development company.

The post The best remote development team appeared first on asap developers.

Thanks to technological advances, remote work has been on the rise for the last few years, and with good reason: it has been proven that companies offering the option to work remotely see a 25% decrease in turnover. Moreover, as we know, working with agile methodologies is the best way to make the most of your resources, decrease the risk of failure and improve your chances of succeeding. It is a faster, more efficient, and more productive way of developing any software. However, implementing agile methodologies for a remote agile team teams does come with its challenges. In this article, we’ll focus on six tips to help you on this front.

1. Foster communication

Fostering communication is essential for any remote agile team, but even more so when it comes to an agile one. The success of a remote agile team depends highly on personal connections and mutual understanding. You should foster communication across all roles by creating opportunities for the team to interact and get to know each other through video conferences, 1:1 video chat sessions, internal blogs or video coffee breaks.

2. Use an online planning board

A planning board is the basis of any agile team. When it comes to working remotely, there are plenty of options to create an online board to manage each project. Jira and Trello are both examples of excellent tools to help you with this area. Jira is almost plug-and-play, giving you the freedom to choose between a Scrum and a Kanban board while customizing many of the details. Meanwhile, Trello is simpler and allows you to create your own board from scratch to meet your specific requirements. It also has the added benefit of being free, unless you require extra features or integrations.

3. Have daily standups and iteration planning meetings

Just because you’re not in the same office, it doesn’t mean you can’t still have daily standups. You can easily use Zoom or Skype to set them up. However, when dealing with a remote agile team that spans different time zones, make sure to schedule communications in the time zone that is most beneficial for all members.

The same applies to iteration planning meetings. They can easily be done online with a video conference call, aided by screen sharing. To make the most of them and ensure they go smoothly, you should make sure there is someone leading the meeting. It is also a good idea to record the meeting for team members to have as reference later on.

4. Foster self-reliance and self-organization

Just like in any agile environment, each remote agile team member needs to be able to take ownership and responsibility for their work organization and environment. This means you need to work on each member’s self-reliance and self-organization as these are essential qualities that have a considerable impact on your project. You should focus on laying ground rules from the get-go, writing down expectations, and making the most of the daily standups. These are tools that will help you work on these abilities and check where each member stands.

5. Define your acceptance criteria

Defining acceptance criteria is a cornerstone of any successful development team. But, when it comes to a remote agile team, it is even more important that everything is crystal clear from day one. You should define all acceptance criteria in extreme detail and add it to the relevant ticket on the planning board. If you share the criteria during the iteration planning meeting, make sure the product owner is present to clarify any doubts that may arise.

6. Document more with remote agile teams

Most agile teams do well enough by documenting just the basic requirements. That said, when working on a remote agile team, documentation becomes all that more important and you should strive to use it as much as possible since remote agile team members don’t have access to a quick on-site explanation of a complex concept. You can also use alternative methods—such as pictures, videos or screenshots—to explain a specific concept or make a point to someone on the other side of your screen.

Final thoughts on remote agile teams

Agile teams run by the same rules whether remote or on-site. However, you’ll have to put more effort into implementing the appropriate tools and making sure all information is getting across when working remotely. Not interacting face-to-face with everyone on a daily basis makes it harder for any team to succeed. However, there are plenty of tools to help you create the best remote agile team possible and work towards an even more successful development company.

The post Remote agile team appeared first on asap developers.

It may sound like we’re about to talk to you about dragons and fairies, but a user story is actually a fairly technical concept, although that doesn’t make it any less interesting. As part of agile methodologies, a user story is the description of a functionality from the user’s perspective. They are usually quite simple, only a few lines long, and don’t go into much detail. User stories also tend to follow the same structure:

As a <user>, I want to/need/can <goal> so that <reason>.

The first part relates to the “who” of the matter: the user, role or persona that will be able or wants to perform a specific action or achieve a goal. The second part of the story relates to that goal and the third part is the “why”: the motivation to perform that action and the outcome or benefit the user gets from it.

Who writes user stories and when?

There is no specific person in charge of user stories. Ultimately, it’s the product owner’s responsibility to make sure they get done, but most likely every member of the team on the project will write one at some point.

These stories are not written at one specific point either but throughout the project. This might involve a story-writing workshop at the beginning of the project to create a product backlog, but new stories can be added later on.

What is the purpose of user stories?

You might think that if you are confident in what you need your app to do, there is not really any point to user stories. However, there are actually several big reasons why user stories are important, if not vital to your project. User stories might seem simple, but they will actually help you define each step in your project more clearly. Here are some of the ways in which they will help you do that:

1. They focus on the user: As we’ve covered in other articles, one of the keys to a successful app is to know the user and provide them with the best experience possible. By keeping the focus on the user, these stories allow you to prioritize them and make sure you focus on the person that will actually use your product.
2. They help gain clarity all around: User stories provide clarity on what you are building, for whom, why and when. They help you make sure the entire team has a clear picture of what they are working towards.
3. They encourage collaboration across the entire team: Unlike coding itself, user stories are simple and don’t make use of technical language. This means any team member (including non-technical ones) can pitch in to define and prioritize user stories, thus having a significant positive impact on teamwork.
4. They help define your product: As we’ve mentioned earlier, user stories describe the product’s functionalities from the user’s perspective. They divide your project into small, simple steps that help you define it and prioritize your tasks according to value for the user and the project’s dependencies and complexity. This means you don’t necessarily have to cut out any wild ideas, but can assign a lower priority to them, focus on the core functionalities first, and see if you have the resources for them later on.

How do I write a great user story?

Now that we’ve covered why you should include user stories in your app project, let’s focus on what a great user story looks like. These are all points you should consider and make sure the whole team understands before getting started.

1. First of all, keep in mind that user stories are not the same as tasks. You may need hundreds of tasks to complete just one story. User stories define, while tasks are used for implementation. You will need to decide which steps need to be completed for each story and who will be responsible for them.
2. Although this may sound repetitive, you will need to focus on the real users of your product. You will have to build their personas, including profiles, points of view, pain points and expectations. Everyone on your team will need to understand the users and think from their perspective. If you have multiple types of end users, you might consider writing multiple stories for them.
3. Don’t be afraid to think big or outside the box. There should be no constraints at this stage of the process. As we’ve mentioned earlier, if a story is too crazy or random, you can assign it a lower priority instead of downright discarding it and see what happens later down the road.
4. Use epics to organize your stories. Epics describe larger pieces of functionality that require more work and include a set of user stories that share a common goal.On the other end of the spectrum, if a story is too big to complete in one sprint, you might consider breaking them down into smaller ones or make them their own epic.
5. Be organized. In the same way you might need to use epics or break down your stories, you will also need to name and categorize them so they are easy to find and prioritize. Avoid renaming or making big changes to a story’s description as this will create confusion. Organization does not stop there, however. You should use tools to help you keep track of your stories and log all of the relevant information. Sticky notes are perfect for brainstorming, but investing in software to manage your project is more than advisable.

What are some examples of user stories?

Now that you have all the basics, let’s look at some real-life examples from The Yoga Collective, one of the apps we’ve developed. This is an online yoga studio where users should be able to subscribe and log in to access the platform and have certain videos and classes available on their dashboard. Taking that into account, let’s start with a simple user story we wrote for this project:

• As a user, I need to be able to log in so that I can access the app’s content.

It might seem rather obvious, but this helps you set up the tasks needed to bring this story to life as well as assign the team members in charge of it.

Then, there are some more complex user stories that include a condition. For example, The Yoga Collective offers paid subscriptions. Subscribers can use the same credentials they use in the app to access the content on the company’s website. With that in mind, we wrote the following user story:

• As a user, if I’m subscribed to the mobile app, I should be able to log in to the web so that I can access the web content.

Finally, let’s take a look at a set of three stories that would be part of the same epic. This epic deals with what users should be able to see on their dashboards once they log in (we’ll drop the “so that” in this case to simplify things):

• As a user, once in the dashboard, I need to be able to see the featured collections section.
• As a user, once in the dashboard, I need to be able to see the trending classes.
• As a user, once in the dashboard, I need to be able to see main featured videos.

Takeaway

In short, user stories are a way to simplify all of your app’s functionalities and help you define your project. They may seem like an unnecessary hassle when you’re eager to get started on a new project, but taking the time to write them will save you precious time later on in development. You can find more advanced information on user stories here.

The post User stories: the key to a great app appeared first on asap developers.

The post What is a pain point? appeared first on asap developers.