DEV Community: Vikash Koushik

Asana vs Trello: Which is better for your team?

Vikash Koushik — Wed, 30 Dec 2020 09:35:01 +0000

When you started your hunt for a new project management software, you most likely considered several tools. And now, you’re weighing in the pros and cons of Asana vs Trello.

As someone who has used both the tools extensively for several periods, I’m going to go in-depth to help you decide which tool you should pick for your team.

Let’s jump in.

Asana vs Trello

Asana takes a task-oriented approach to project management where the main unit of work is a task. Trello is a project management software where everything is a card. It mimics a real-life Kanban Board that you’d have with sticky notes on different columns.

Trello is simple and easy to use. But you’re likely to feel like you’ve hit a wall as your team expands. Asana on the other hand is relatively harder to get started but has more capabilities than Trello.

Before we jump into the details, let’s take a quick overview of Asana and Trello.

Quick Overview of Trello

Trello was founded in 2011 and launched in Techcrunch Disrupt. Founded by Joel Spolsky and Michael Pryor, Trello quickly became popular among many teams and individuals alike.

In 2017, Atlassian, the maker of JIRA, acquired Trello. After all, a lot of development teams would often compare Trello vs JIRA, begin using Trello, but naturally switch to JIRA when they need more functionalities. However, this is changing. With tools like Zepel having a perfect balance between Trello and JIRA, more teams are less inclined to use JIRA.

When it was founded, Trello was possibly the only tool that took a radically different approach to project management. Instead of focussing on projects, Trello decided to focus more on the workflow of the task. This meant, Trello had only three things — Boards, Lists (or Columns), and Cards.

Trello Board

Since Trello mimics an actual Kanban Board, it gives teams the flexibility to consider each board as a project by itself. Columns represent the statuses through which each card would flow through. And the actual discussions and collaboration happen inside the card.

In plain words, if you or your team used a Kanban Board with sticky notes at your office (when people used to go to offices), then using Trello will be super easy for you.

The visual approach to project management by Trello enables you and your team to quickly see “who is doing what”.

By organizing your Trello board by different statuses of progress, you can move each card from one column to another as progress is made on that specific task.

For example, if you’re using Trello for web development, you might name each column as “Todo”, “Prioritized”, “In Progress”, “Reviewed”, and “Done”. You’d add each task under the “Todo” column and as you make progress on each task, you’d move it from one status to another till it’s moved to “Done”.

Of course, you can choose to edit the names of the columns to meet your team’s needs.

When you want to have discussions, set due dates, assign a card to a teammate, add labels, upload attachments, and descriptions, you can open up each card to add them.

Quick Overview of Asana

Asana was started by former Facebook founder Dustin Moskovitz and early Facebook employee Justin Rosenstein in 2008. It was kept in private beta for almost four years before they launched commercially for the public in April 2012.

Asana is centred around projects. Within each project you create, you can create sections to categorize tasks. Each task can have subtasks, descriptions, assignees, tags, comments, and custom fields.

However, if you want to view a nestled view of all the tasks and subtasks, that is not possible.

Boards in Asana

After you’ve selected/created a project, you can create tasks by clicking on the plus button from the top. To add other details to the task, clicking on the specific task will open its details panel from the right of your screen. This detailed view of the task will also have a timeline of all the activities of the tasks.

You can choose to view these tasks either in List, Board, Timeline, or Calendar view. All comments and other notifications related to the project are collected in a separate tab inside Asana called the “Inbox”.

Views and other features

Trello primarily being a kanban software, doesn’t come with any other views built-in. All you’ve got is a kanban board view and that’s it. If you want other views such as Gantt or calendar, you can choose to use one of their 3rd-party “power-ups”. However, there are no power-ups to view everything in one single list. And you might end up paying a lot for it (more on this later).

Asana, on the other hand, has several views baked-in to the product. It comes with views such as List, Board, Calendar, and Timeline (Gantt). But their pricing plans restrict you to List, Board, and Calendar views on the free plan.

Of course, other features such as assignees, due dates, comments, tags, file attachments, and integrations are available on both Asana and Trello. You should note that only Trello allows you to add multiple assignees for a task similar to Zepel.

Verdict: Purely based on the number of features and views available, Asana is a clear winner compared to Trello.

Pricing

First things first. I’m sure you’re already aware of this, but I thought I should mention it anyway. You shouldn’t have to choose project management primarily based on pricing and sacrifice your team’s productivity.

If you’re getting more capabilities out of a tool and your team requires those capabilities to perform at their best, then a few $$ shouldn’t come in their way. But of course, if the capabilities of a free project management software are good enough for your team for now, then great!

With that out of the way, let’s compare the pricing of Trello vs Asana.

Trello Pricing

Much like many project management tools, Trello also follows a freemium pricing model. They provide you with a certain set of basic features for free. But when you need more capabilities and power, you’ll have to start paying them.

Trello’s pricing starts at $0 with a limited set of features and works its way up to $9.99 per member per month (when paid annually) or $12.50 per member per month (when paid monthly). Trello’s enterprise plan starts at $17.50 per member per month.

A point to note about Trello’s free plan is it’s free for unlimited users. They begin per user to charge only when you need more features.

Trello pricing

As you start using Trello more frequently, you’re likely to want to use their premium features and end up paying for it. Some features you might want to pay for include higher limits on file attachments, custom fields, and more number of power-ups.

For example, on the free plan, you can use only one power-up per board. This can become tricky if you want to add more views like Calendar or Gantt using Trello’s power-ups. Not only will pay extra for Trello to use more power-ups, but you might also have pay to the 3rd parties who built the power-ups.

Asana Pricing

Asana’s pricing plans also follow a freemium model.

Asana’s pricing starts at $0 for a limited set of features for 15 members. Its premium plan costs $10.99 per member per month (when paid annually) or $13.49 per member per month (when paid monthly). Business plan costs $24.99 per member per month (when paid annually) or $30.49 per member per month (when paid monthly). If you want an enterprise plan, you’ll have to contact their sales team.

Asana pricing

At first sight, it looks like Asana charges about a dollar more than Trello. However, you should also keep in mind that Asana’s free plan does come with more features compared to Trello.

Verdict: Draw. Considering the number of features and capabilities that comes from the two tools for at a price that’s nearly the same, it’s hard to pick one over the other.

NOTE: Keep in mind that while Asana is free to use for 15 members when you add your 16th member, you’ll be charged for all 16 members on the premium plan. Trello’s pricing is also similar.

Zepel, on the other hand, is free forever for the first 5 members. When you add your 6th member, you’ll be charged only for the 6th member and not for the first five.

Collaboration

Collaboration in both Trello and Asana are pretty straightforward. Both tools have the usual collaboration-focussed features like descriptions, assignees, due dates, tags, comments, and file attachments.

Trello allows you to collaborate with an unlimited number of users even if you’re on the free plan. This, of course, is a huge bonus for small teams who might not need a lot of features.

Asana limits you to 15 members on the free plan even if you don’t want to use their premium features. Unlike Trello which allows you to upload up to 250MB per file (at least if you upgrade), Asana only allows a maximum limit of 100MB per file even on a higher paid plan.

Verdict: Trello is a clear winner over Asana thanks to them allowing an unlimited number of collaborators even on the free plan.

Dependencies

Among all collaboration specific features, dependencies have to be one of the most important ones in a project management tool.

Trello, unfortunately, doesn’t have capabilities that allow you to mark dependencies between cards. This is where Asana beats Trello.

Asana lets you add dependencies between tasks and view them on a timeline (Gantt). This timeline view is especially useful when you want to manage conflicts between dependencies.

Dependencies in Asana

However, you must keep in mind that unlike Zepel, dependencies in Asana is not available in the free plan. Asana users can use dependencies only if they subscribe to a premium or higher paid plans.

Verdict: Comparing Asana vs Trello, the clear winner when it comes to managing dependencies is Asana.

User experience and ease of use

Both Trello and Asana have invested a great deal into building software that’s easy to use and has a great user experience.

Trello, as you might already know, is known for its ease of use. If you had to gather your entire team in one room and explain to them how Trello works, it wouldn’t take you more than 10minutes. This makes it an obvious choice for many teams to select Trello since it removes the burden of onboarding your entire team and getting them to use it.

Adding details to a card in Trello

Unlike Trello, you might not be able to explain all of Asana and get your team on board in a few minutes. Of course, you could argue that it’s also partly because Asana has more functional capabilities.

To make things easier, Asana uses a left nav-bar for navigation and has specific tabs inside the project for different views. Asana also has Sections to help you categorize tasks under specific buckets.

Both Trello and Asana have detailed documentation and a helpful community if you ever feel stuck.

Verdict: Trello, if you want to get started immediately. Asana, if you need more power and okay with taking some time to onboard your team.

Integrations

3rd party integration in both Asana and Trello is pretty solid. Both tools have a huge list of tools (100+) they integrate with. They’ve got Slack, InVision, Dropbox, Salesforce, Hubspot, and many more!

If you can’t find a tool you’re using in their list, then you might be able to use Zapier to get the integration working.

If you’re a development team using either of the tools, then you might want to note that while both Trello and Asana have integrations with GitHub, Bitbucket, and GitLab, neither of them are as deeply integrated as some of the other tools like Zepel.

Verdict: Draw.

Pros and Cons of Trello

Pros of using Trello

Effortless to get started.
Easy to get team onboard.
Supports several use cases. From blog calendar to software development.
Free to use for unlimited users.
Helps you quickly see what’s happening.
Advanced filters help you find what you want.
No credit card required to get started.

Cons with Trello

Doesn’t have import functionality if you’re coming from other tools.
You can’t export your data if you’re on the free plan. This locks teams inside Trello.
Can become extremely hard to manage software projects. This is where teams begin to look for Trello alternatives.
Its flexibility can get misused and make the Trello board a mess to manage.
No list view.
Lacks / commands to get work done quickly.
Has half-baked agile capabilities. Lacks several capabilities for agile software development.

Pros and Cons of Asana

Pros of using Asana

Custom tags.
Reasonably easy to use interface.
Several views to visualize projects.
Many integrations.
Ability to view tasks assigned to you.
Several quick filters.
Saved templates.

Cons with Asana

No ability to add multiple assignees.
Can get expensive pretty quickly.
Free plan restricted to just 15 members.
Steep learning curve
Impossible to view tasks and subtasks in one single view.
Doesn’t have / commands to get work done quickly.
Does not have capabilities of a full-fledged agile tool.

Which is better? Trello or Asana?

As you can see, comparing Asana vs Trello both are equally good. Tool ideal for your team depends largely on your use case.

If you’re a small engineering team, Trello might be better for you. If you’re a non-technical team (marketing, sales, customer success), then Asana might be a better option.

If you’re a larger engineering team, neither Trello nor Asana might be right for you. You might want to compare and consider some of the popular Trello alternatives. And if you’re a large non-technical team, Asana might work fine for you. However, if you’re using Asana and have dependencies with your engineering team, you could connect Asana as a source to Zepel and send requests.

Alternatives to Asana and Trello Alternatives

Of course, there are several alternatives to Trello and Asana alternatives out there. In case you still aren’t too sure, below are X tools you might want to consider:

1. Zepel

Zepel is an ideal alternative for Trello and Asana if you’re a team building software products and are looking for more power.

Zepel supports agile methodologies (both Scrum and Kanban), has functional reports, and developer-friendly features that’d keep your team productive.

Unlike other project management tools, Zepel also lets you bring customer feedback and bug reports from other tools (Zendesk, Sentry, Intercom, and more), so you can prioritize with context and build customer-focused products painlessly.

Your first 5 members are free forever even when you add more than 5 members. Zepel pricing doesn’t restrict you on features even if you’re on the free plan. The standard plan starts at $5/member/month when paid annually and $7/member/month when paid monthly.

2. JIRA

JIRA is the industry standard. Software teams who want agile capabilities gradually switch to JIRA when other tools aren’t powerful enough for them.

However, over the last few years, this trend has been changing. Teams are frustrated with how clunky and slow the tool is. This has led most modern teams to look for a JIRA alternative.

Your first 10 members in JIRA are for free. However, there are some feature restrictions. Also, when you upgrade to the premium plan that starts at $5/member/month , JIRA pricing model forces you to pay for your first 10 members which were initially for free.

If you’re one of those teams who is unhappy with JIRA, you might be interested in this list of tools like JIRA.

3. Basecamp

Basecamp is an ideal alternative to both Trello and Asana if you’re a services company that’s remote and isn’t specific about needing views like Kanban or Gantt. It founded in 1999.

Basecamp’s primary features include task tracking, to-do lists, a forum-like view for team messaging, file sharing, a check-in request for standups, and time tracking.

Basecamp pricing is simple. You can start a free 30-day trial and use all its features. Once the trial is up, you pay a flat fee of $99/month for an unlimited number of projects and users.

4. Notion

Notion took the industry by a storm when it launched publicly in June 2018. Notion is an all-in-one productivity tool that lets you use it as a project management tool, note-taking app, and more.

It’s simple to use and allows you to mould it in any way you want. It’s so flexible, several teams use Notion as an alternative to Trello, Asana, and even Evernote.

It's free to use. You can invite up to 5 guests. If you want more features, Notion pricing plan includes multiple paid plans that range from $4/month to $8/member/month.

5. Wrike

Wrike has been around as a project management tool for a while and is a solid tool for non-technical teams considering Trello or Asana.

Similar to Asana, it supports Kanban Boards, Gantt, time tracking, request forms, calendar views, and deep integration with Salesforce, MS Projects, Excel, Google Drive, Dropbox, and others.

Wrike has a free plan for up to 5 members and limited features. If you want more features or want to add more members, their pricing plan ranges from $9.80/member/month to $24.80/member/month.

Why choose Zepel over Trello or Asana?

Zepel is the simplest project management tool built for software product teams. It’s built to remove all the frustrations and eliminate inefficiencies teams have during their development process.

With capabilities to bring your customer’s exact words into the tool for easy prioritization, boards, sprints, reports, advanced filtering, and more, Zepel makes it effortless to build customer-focused software.

Zepel takes a step further to make the development process easier with features like / commands, markdown editor, hierarchical view, chrome extension, and deep integrations.

The best part, you can import your existing data from other tools in one-click and play around with Zepel for free without any strings attached.

Try Zepel for free.

11 Best Asana Alternatives for Project Management in 2022

Vikash Koushik — Mon, 28 Dec 2020 06:53:58 +0000

I remember the first time I tried Asana in 2014. It was a simple project management tool, easy to use, and had fancy unicorns flying all over.

Since then, Asana has added several features and capabilities. It's made Asana a popular project management software with several thousand teams quickly adopting it. However, there are some reasons why you might want to look for an Asana alternative.

Before we jump in and look at the top alternatives to Asana, let’s look at its limitations.

5 reasons why you should look for an Asana alternative

1. Lack of Hierarchical View

Asana has subtasks, but you can’t view them in a hierarchical order. This makes it extremely difficult if you want to view all the tasks and subtasks in one single view.

2. Unfriendly Pricing

Sure, you can use Asana for free. However, the free Asana version has heavy limitations in terms of its capabilities. And when you choose to upgrade to use some of the premium capabilities, you’re likely to burn a hole in your pocket with their steep pricing plans. For example, to set up dependencies between task items, you’ll have to upgrade to their premium plan!

Asana’s premium version starts at $13.49 per user per month and goes all the way up to $30.49 per user per month.

Ouch!

3. Lack of Developer-Friendly Capabilities

If you’ve got developers using Asana, then you’ve probably heard them being unhappy with the tool. After all, Asana doesn’t support markdown and lacks deep integrations with GitHub, Bitbucket, or GitLab.

4. Missing Agile Capabilities

While Asana’s board view is great, it still lacks some key agile capabilities if you want to use it as an agile project management software. For example, it lacks a dedicated sprint view that scrum teams can use. This makes Sprint planning, getting an estimation of how your sprint is progressing very hard.

5. No Functional Reports

Of course, when you’re building software products you’re likely following some form of agile methodology. If you’re one such team, you’ll notice that Asana doesn’t provide reporting capabilities such as burndown charts, burnup charts, cumulative flow diagrams, and more.

11 Alternatives to Asana for Project Management

1. Zepel

Zepel is the project management tool built for software product teams. If you’re a team that has a mix of developers, product managers, and designers, then you’ll find Zepel to be a great alternative to Asana.

Here’s why:

Zepel is simple and flexible enough that it supports both kanban board and sprint with robust reporting capabilities. It comes with deep integrations with tools that developers and the rest of the team use every day.

Boards in Zepel

You also get the ability to bring all your customer conversations (feedback, feature requests, and bug reports) from several tools inside Zepel. This way, you can prioritize with the context of actual words your customers said.

Key features of Zepel:

Hierarchical document view to plan features and see all work items including subtasks in a single shot.
/ commands to quickly get started without any overhead.
Kanban Boards with advanced filtering to easily view who’s doing what and track their progress.
Sprints with agile reports to keep track of sprint progress.
Scrum boards with advanced filters to easily visualize the progress of the sprint.
Activity feed to see what happened and when.
Add dependencies between work item and add external links to give your team more context.
Progress view that accumulates the progress of all work items to track the progress of an entire feature.
Deep Git integration (GitHub, Bitbucket, and GitLab) to make it easier for developers to stay productive. Connect Zepel to other tools such as Figma, Slack, Sentry, Intercom, Zendesk, and more.
Markdown descriptions, comments, @ mentions, and unlimited file uploads.
Import from Asana

Pricing:

5 members free forever. No feature restrictions.
Standard plan starts at $5/member from 6th member.

Frustrated with Asana? Try Zepel for free ➞

2. Trello

It’s impossible to write a best Asana alternative article and not mention Trello in it. Before Trello was acquired by Atlassian, they were one of the biggest Asana competitors.

Trello took the project management industry by a storm when they came out purely because of its ease of use. When it was first introduced, Trello was one of the easiest Asana alternatives to get started. It’s simple and pretty much anyone with any use case can use it.

The problems with Trello is that they don’t scale that well for a growing organization. With little to no first-class reporting, limits on the file uploads, and the lack of advanced features such as marking dependencies between work items makes growing teams end up looking for Trello alternatives.

Key features of Trello:

Simple and easy to use
Kanban boards with a limit on the file attachment
Checklists
A host of integrations to connect to other tools

Read the detailed comparison of Trello vs Asana

Pricing:

Free to use for 10 boards. Has limits on feature usage.
Standard plan costs $12.50/member/month.
Enterprise plan costs $17.50/member/month.

Check out our detailed comparison review of Trello vs Jira ➞

3. Monday.com

Monday is a popular alternative to Asana since it’s also a work management tool.

Thanks to the templates and automation that you can set up, Monday is widely adopted by non-technical teams. This makes it effortless for teams to collaborate and keep teammates/clients always in sync.

Another unique aspect of Monday is their customizable reports that are tailor-made to fit teams like marketing, sales, customer success, and human resources.

Key features of Monday:

Several views - Tabular columns, calendar, Gantt, forms, and more.
Ability to automate certain tasks.
Customizable reports that match the needs of certain non-technical teams.
Several apps to connect with.

Pricing:

No free plan. Offers a 14-day free trial.
Pricing starts at $10/member/month to $20/member/month.
Has restrictions on what features are available depending on the plan you choose.

Bring your teammates' requests from Monday.com to Zepel for easy prioritization ➞

4. Smartsheet

If you want to switch back to using a spreadsheet as your project management tool, then you should consider Smartsheet as an Asana alternative.

As the name suggests, Smartsheet is what you’d likely get if spreadsheets had native project management capabilities. It’s packed with features like multiple views, reports, admin centre, and integrations. With all the features packed in, one disappointing thing note would be its outdated design that could leave a bad first impression for many teams.

Key features of Smartsheet:

Multiple views (Gantt, Grid, and Calendar)
Activity feed
Resource management capabilities that are ideal for client services teams.
Reminders and integrations

Pricing:

No free plan. Offers a 30-day free trial.
Pricing starts at $14 per month to $25/member/month.

5. Wrike

Wrike was started in 2003. It’s centred around the concept of folders and nested folders.

As an alternative to Asana, one of Wrike’s best aspects is its flexibility. It enables everyone to work the way they want and provides several views to help them do just that.

A unique capability of Wrike is that it provides not only file sharing, but also editing capabilities. This makes it easier for teams to share knowledge internally and collaborate.

Key features of Wrike:

Real-time activity feed
Task management capabilities
Time tracking
Visual proofing of documents
Gantt charts and Kanban Boards

Pricing:

Free for 5 users.
Pricing plan starts at $9.80/member/month to $24.80/member/month.

6. nTask

nTask manager is a free Asana alternative and it comes at an affordable price.

nTask manager has everything you’d expect in a project management tool — assignees, team-specific workspaces, and Gantt charts. What’s unique about this project management software is that it also has support for managing meetings and timesheets. This is particularly helpful if you’re a freelancer.

A downside to this tool is the lack of Kanban Boards that you’d expect in an alternative to Asana.

Key features of nTask:

Team specific workspaces
Convert comments tasks
Gantt charts, projects
Timesheet & meetings management

Pricing:

Free with limited features.
Pricing starts at $3.99/member/month to $7.99/member/month.

7. Nifty

Nifty looks a lot like Asana in terms of its design. The colours and to a certain extent, even the layouts.

Nifty is a good Asana alternative since it has capabilities to help your team manage projects, track milestones, goals, and even your files. Apart from the usual features you’d expect in a project management software, a couple of Nifty’s key features include the integration with Google Docs for easy collaboration and its ability to send group and individual messages.

Key features of Nifty:

Gantt charts
Tasks
Projects
Reporting that allows you to manage workload
Time tracking

Pricing:

No free plan. Comes with only a 7-day free trial.
Starts at $49 for 10 members per month with limited features.

8. ClickUp

ClickUp is the all in one productivity tool. It’s got everything from mind-mapping capabilities to advanced project management features. This means you can customize the tool to any extent and have your team’s requirements met.

While some consider ClickUp’s buffet of features a positive sign and a great Asana alternative, many also find it overwhelming and sometimes confusing. This is possibly the only thing that you may have to watch out when considering ClickUp for your team’s needs.

Key features of ClickUp:

Tasks and subtasks
Goals
Gantt charts, list view, mind maps
Kanban View
Time tracking and due dates

Pricing:

Free plan with feature limitations.
Pricing starts at $9/member/month to $19/member/month.

9. Teamwork Projects

Among many other products that Teamwork has, Teamwork Projects is one of them and are a solid Asana competitor.

Teamwork is ideal for marketing teams, IT teams, universities, and agencies. It has kanban boards with time tracking and the ability to manage resources. With the dashboard, project updates, and filters, Teamwork makes it easy for managers to stay on top of the team’s progress.

Key features of Teamwork Projects:

Task history
Time tracking
Kanban view, Gantt chart, and Portfolio management
Permissions

Pricing:

Free for up to 5 members and 2 projects
Paid plan starts at $12.50/member/month to $22.5/member/month depending on the features you choose to use.

10. Toggl Plan

Toggl Plan is built around two main views — Kanban Boards and Gantt.

As an alternative to Asana, one of the things that Toggl plan lacks is the list view. Apart from features such as assignees, due dates, and file attachments, Toggl also comes with private projects, milestones, and capabilities to manage workload.

Key features of Toggl Plan:

Kanban Boards, Gantt charts
Private projects and milestones
File attachments, recurring tasks
Time tacking (it’s a separate product of Toggl’s)

Pricing:

Free for up to 5 members with restrictions on features.
Standard plan starts at $9/member/month to $15/member/month.

11. Workzone

Workzone is a great example of a project management software with plenty of features that don’t overwhelm you.

Workzone comes with a project dashboard, Gantt charts, calendar view, and personalized to-do lists. As an Asana competitor, Workzone also has project request forms that you can customize to your needs.

A disappointing aspect of Workzone is its lack of a free plan or even a trial. Also, its search feature requires improvement as believed by many of its users

Key features of Workzone:

Project dashboard
Customizable forms and reports
Todo lists personalized to each member
Gantt charts and calendar views

Pricing:

Workzone doesn’t provide a free plan or a free trial.
Paid plans start at $24/member/month to $43/member/month.

Creating a New Branch in GitHub Made Effortless

Vikash Koushik — Fri, 09 Oct 2020 14:35:09 +0000

It took me a while to understand the importance of branches and how they work.

To most developers, this must sound all too familiar. That’s why I’m going to break it down for you. No more confusion and no more double-checks.

Branches in GitHub (and Git) allow you to take the original codebase, create an exact replica of it, make changes, and then submit your changes to be merged into the original code base.

This way, you can make sure the final code base is always bug-free. Or at least not disastrous.

In our previous articles, we covered some of the basic git commands and saw how you can improve your development process with git workflows.

How Branches in GitHub and Git Work

GitHub (and Git) enables you to control which version of the code gets deployed to your production.

And branches play a fundamental role in this.

Every time you deploy code to production, you’ll obviously want to make sure you’re only deploying the most stable version.

But how do you make sure you always have a stable version ready for deploy when you’ve got multiple teammates constantly working on new features and bug fixes?

By creating multiple branches.

Every repository (ie. your code base) in GitHub can have multiple branches.

The main branch, often called the Master branch, is the official stable version of your code. This is the branch that gets deployed to production.

And it’s also the branch that’s never edited directly. Especially when you’re working collaboratively.

So when you want to make changes, you’d create a new branch from the master branch, make your changes in it, and when you’re ready, you’d request your changes to be merged into the master branch.

Here’s a visual example of how working with multiple branches might look like:

Git workflow with feature and develop branches

Which brings us to the question of how to create a new branch in GitHub?

There are three ways you can create a new branch in GitHub:

Using GitHub's website.
Using GitHub's desktop app.
Using command line.

Let’s dive in and look at all three of them.

Creating a New Branch From GitHub Website

Navigate to the main page of the GitHub repository for which you want to create a new branch.

You’ll see the name of your current branch in the branch selector dropdown. To see all the branches in the repository, click on [NUMBER Branches]. In my case, you can see that I’m currently on Master branch and I have 2 branches.

Viewing all branches in your GitHub repository

To create a new branch, click on the branch selector dropdown and start typing the name of the new branch in the text box.

Type the name of your new GitHub branch in the search box

By default, this text box checks if there’s an existing branch with the name you just entered.

If not, you’ll be able to create a new branch by selecting “Create Branch”.

Click create branch

This will automatically create a new branch with the Master branch as your base branch.

However, to switch and edit your code from the new branch you just created, you’ll still have to use GitHub’s desktop app or the terminal code. That’s why, most developers prefer to just use the desktop app or work using terminal commands.

Let’s see how you can do that as well, shall we? :)

Creating a New Branch Using GitHub Desktop App

Creating a new branch on the GitHub Desktop app is identical to how you’d create on the website.

Make sure you’ve got GitHub's desktop app downloaded before reading further.

Once you’ve got the desktop app open, navigate to the repository in which you want to create a new branch.

Now, click on the branch selector dropdown and click "New Branch" button.

Click the "New Branch" button from the Branch Selector drop down

In the create new branch pop-up, enter the name of your new branch and click the “Create Branch” button.

Enter the name of your branch and click "Create Branch"

Alternatively, you can use the shortcut key Cmd + Shift + n (or Ctrl + Shift + n if you’re on Windows) to create a new branch.

To begin making changes to this branch, simply hit Cmd + Shift + a (or Ctrl + Shift + a if you're on Windows) to open your code in your code editor.

It's important to remember that while a new branch might be created, it will not be accessible to everyone unless you publish it to the remote location. You can choose to make all the code changes, commit them, and then publish your branch. Or, you can click on the “Publish” button.

Zepel Tip

Oftentimes, a branch is created by the developer when they begin working on a new feature or a new bug-fix.

Instead of manually updating the team about the progress, developers can automatically change statuses and keep everyone updated

All you have to do is, enable the GitHub integration with Zepel, edit your workflow, and link your work item to your branch.

Using Command Line to Create New Branch in GitHub

Creating a new branch using the command line is nearly every developer’s favourite method. Because once you get a hang of it, it’s unbelievably easy to use.

First, make sure to cd into your local repository. Once you’re in the right folder, execute

$ git branch <branch-name>

This will create a new branch. But before you start making changes to your code, you will have to first switch to the new branch you just created. To do that, run

$ git checkout <branch-name>

Many developers, especially when they’re just getting started, forget switching to the new branch. That’s why you can use this command that will create the new branch and immediately switch you to it:

$ git checkout -b <branch-name>

Once you’ve created a new branch and switched to it, you can start making changes in your code. However, all of these changes (including the new branch) is still only in your local machine.

To publish the new branch you created in GitHub and make it available for everyone in your team, run the following command:

$ git push -u <remote> <branch-name>

Zepel Tip

If you use Zepel as your agile project management tool, you can create a new Feature for every feature you build.

With the help of deep GitHub integration, you can link the Feature to a branch in GitHub and Zepel will automatically update progress within your team.

Say you're working on Public API for your product. You'll create a feature called Public API in Zepel, create tasks for it, and link the feature to your new Branch using the command suggested by Zepel: This way, you can spend all your time building quality software while Zepel does the grunt work for you.

With Branches in Git and GitHub, working on code collaboratively is a lot easier than it used to be. While there can still be inefficiencies in your development workflow, a lot of it depends on the intricacies of it.

However, if I must leave you with one thing, never directly make changes to your master branch. Nothing good has ever come off it.

13 Git Commands Every Developer Must Know

Vikash Koushik — Thu, 01 Oct 2020 14:29:53 +0000

I can’t begin to tell you how confused I was when I first started learning Git commands.

"I typed git commit. Why didn’t my teammate get my changes? Oh, I have to do git push as well?!"

I’m sure I can list at least a dozen occasions where I was totally confused with Git commands and what they did.

That’s why I'm going to share 13 frequently used Git commands in this blog post.

Of course, there are more commands. But to avoid overwhelming you, we’ll cover just the ones you’ll use frequently.

Here are 13 Git commands that can speed-up your development workflow and allow you to go from a brand new repository to merging it.

1. Git Init

The git init command is usually the first command you’d run in any new project that is not already a Git repository.

It can be used to convert an existing, un-versioned folder into a Git repository. Also, you can use it to initialize an empty repository.

Using Git Init Command

cd into the directory you want to initialize.

Then, run this command.

git init

This will transform the current directory into a Git repository. A .git sub-directory will be added. This will allow you to start recording multiple versions of your project.

Note: Running git init on an already initialized directory will not override any of your settings.

2. Git Clone

The git clone command is used to download the source code from a remote repository (like GitHub, Bitbucket, or GitLab).

Using Git Clone Command

git clone <https://url-of-the-repository>

When you clone a repository, the code is automatically downloaded to your local machine.

As a convenience, the downloaded version is linked to the origin (the repository from where you downloaded). I say this is a convenience because when you’re collaborating on the same project, you’d want to push your changes (more on that below) to a single repository.

But sometimes, people wouldn’t want to have this link. If your use case is similar, run

git remote rm origin

This will disassociate the downloaded repository from the origin.

3. Git Branch

Branch is one of the most important functionalities of Git. This allows teams to work on the same code base in parallel. It enables teams to create Git Workflows and make their workflows more efficient.

Say, you’re working on “Feature A”. And your teammate is working on “Feature B”. By creating a separate branch for each feature, both of you can work on the same code base in parallel without having to worry about conflicts (at least while you’re writing the code).

You can use this command to create a new branch, view existing branches, or delete a branch.

Using Git Branch to create a new branch

git branch <branch-name>

This command will create a new branch only in your local system. If you want this to be visible to all the members in the repository, you’ll still have to push the branch.

To push a newly created branch, run git push -u <remote> <branch-name>

Command to view all branches

git branch

git branch --list

Git command to delete a branch

git branch -d <branch-name>

4. Git Checkout

A mistake I often made when I first started learning git commands was forgetting to switch to the new branch I just created. Yes, after you create a branch, you’ll have to switch to it with another command. That’s where the Git Checkout command comes in.

Using Git Checkout Command

git checkout <branch-name>

This will automatically switch you to the branch name you mentioned in the command.

However, when switching from one branch to another, you need to keep two things in mind:

If you made some changes in the previous branch, you will have to first commit and push them (I’ll cover this command below) to your remote repository.
The branch you want to switch must be present in your local system. If not, you can pull them (covered below).

If you’re as lazy as I am, I’m sure you’d want one single command that will both create a new branch and automatically switch to it.

The below command does exactly that.

git checkout -b <branch-name>

5. Git Add

Every time you create a new file, delete it, or make a change, you’ll have to tell Git to track it and add it to the staging area. Otherwise, the files you made changes to wouldn’t be added when you try to push your changes.

Using Git Add Command

git add <file-name>

This command will add only a single file to your next commit. If you want to add all the files to which changes were made, you can use

git add -A

It’s important to remember that using git add will not make any changes in the remote repository. Your changes will be recorded only when you commit them.

6. Git Commit

Think of Git Commit command like a checkpoint in your development process.

It’s commonly used to save your changes. Maybe after completing a specific work item assigned to you in your agile tool.

Every time you commit your code changes, you’ll also include a message to briefly describe the changes you made. This helps other team members quickly understand what was added, changed, or removed.

Using Git Commit Command

git commit -a

This will commit all the changes in the directory you’re working in. Once this command is run, you’ll be prompted to enter a commit message.

Alternatively, you can enter the commit message in the command itself and skip the additional step where you’ll be prompted to enter the commit message.

To do this, run the following git command:

git commit -am “<commit-message>”

Note: The git commit command saves the changes only in your local repository. It does not push to the remote origin and make your changes accessible for others to collaborate.

7. Git Push

To make all your committed changes available to your teammates, you’ll have to push them to the remote origin.

Using Git Push Command

git push <remote> <branch-name>

It’s important to remember that git push command will upload only the changes you’ve committed.

8. Git Pull

Of course, you’d want to have the latest updates from teammates as well!

The git pull command allows you to fetch all the changes that your teammates pushed and automatically merge them into your local repository.

Using Git Pull Command

git pull <remote>

In many cases, you will run into conflict because you had changed a line in a file that another teammate added. In such cases, you need to resolve the conflicts manually.

9. Git Diff

Git Diff is my go-to command when I want to quickly see the difference between my current branch and another branch (usually the branch I’m merging into).

Using Git Diff Command

git diff

This will show you any uncommitted changes in your local repository.

To compare two branches

git diff branch1..branch2

This will show all the file differences between the two branches.

To compare a file from two branches

git diff branch1 branch2 ./path/to/file.txt

This command will show a comparison of the changes made to file file.txt across the branches branch1 and branch2.

10. Git Stash

Git Stash temporarily shelves your work, so you can switch to another branch, work on something else, and then come back to this at a later time.

It’s perfect if you need to work on something else and you’re midway through a code change, but aren’t ready to commit the code.

Using Git Stash Save Command

git stash save “<stash-message>”

This will stash your changes with the message you entered. This can be helpful when you want to come back and restore your stash, especially when you have several stashes.

However, this will only stash your tracked files that you added using git add. If you want to include the untracked files as well, run

git stash save -u

Using Git Stash List Command

When you want to view all the stashed code, you can view them using this command. Once you stash your code, git will assign a stash id, so you can restore a specific stashed code later.

For example:

git stash list

This might show the following

stash@{0}: On master: Stashed with message1
stash@{1}: On master: Stashed with message2

Using Git Stash Apply Command

This will automatically restore and apply the topmost stash in the stack.

git stash apply

If you want to restore a specific stash that you want to apply, using the above example, you can simply run git stash apply stash@{1}.

Note: When you use git stash apply, the stashed version will be applied to your current working branch. However, it will not delete the stash from the stack.

Using Git Stash Pop Command

To automatically also delete the stash from the stack, the git stash pop command is used.

If you want to do it for a specific stash in the stack, run git stash pop stash@{0}.

11. Git Status

When you’re feeling a bit lost with what’s happened in your repository (yes, it can happen) the Git Status command can tell you all the information you’ll need to know.

Using Git Status Command

git status

This can give you information such as:

Your current branch
Whether your current branch is up to date
If there’s anything in the branch that needs to be committed, pushed, or pulled.
If you have any files that are either staged or not staged.
And if you have any files that are created, modified, or deleted.

12. Git Log

While git status gave you nearly all the information you’d have needed, it wouldn’t give you the information about the commit history for the repository.

This is where the git log command comes into the picture.

Using Git Log Command

git log

This displays the entire commit history. If your commit history is large, it’ll show only a portion of it and you can hit [space] to scroll or type q to quit.

If you want to view only the last 3 commit history, you can use the following command: git log -n 3.
To condense the commit history into a single line and view them, run git log --oneline. This is the easiest way to get a high level overview of all the commit history. It might still be a bit too much if you’ve got a lot of commits.
If you want to view the commit history by a specific author, run git log --author"<author-username>".

13. Git Merge

Once you’re done with development inside your feature branch and tested your code, you can merge your branch with the parent branch. This could be either a develop branch or a master branch depending on the git workflow you follow.

When running a git merge command, you first need to be on the specific branch that you want to merge with your feature branch.

Let’s see how to use the git merge command with an example.

Using Git Merge Command

Imagine you’re currently in your feature branch called feature1 and you’re ready to merge it to the develop branch.

We must first switch to the develop branch using the checkout command.

git checkout develop

Before merging, you must make sure that you update your local develop branch. This is important because your teammates might’ve merged into the develop branch while you were working on your feature. We do this by running the pull command.

git pull

If there are no conflicts while pulling the updates, you can finally merge your feature1 branch into the develop branch.

We do this by using the git merge command followed by the branch name that we want to merge into our current branch.

git merge feature1

Streamline your Development Workflow

These 13 git commands should enable you to go from creating a brand new repository all the way to merging it to the parent branch.

But as a developer, your work doesn’t stop there.
One of the things you’ll have to constantly juggle is updating your progress in your project management tool.

That’s where you should look for an agile tool that goes beyond being just another project management tool and lifts some weight off your shoulders!

3 scrum artifacts and how to use them

Vikash Koushik — Mon, 20 Jul 2020 08:17:54 +0000

The three scrum artifacts are:

Product backlog
Sprint backlog
Product increment

These scrum artifacts play a pivotal role in helping the scrum team deliver their best work.

Some teams consider the burnup and burndown charts as a part of the scrum artifacts. While these agile metrics are equally important, they represent only the historical details of the work done.

So what exactly are the artifacts of scrum? How do they connect to the scrum framework?

In this post, we’ll dive into each artifact in detail and look at how the scrum artifacts connect to the scrum framework.

What are scrum artifacts?

Scrum framework requires a cross-functional self-organizing team to work together. For this to be efficient consistently, the scrum team needs to have all the right information on what work should be done.

This is where the scrum artifacts come in.

The three scrum artifacts ensure the scrum team stay aligned as they work towards achieving the goal.

Scrum artifacts are the places where the team negotiates what work should be done, what their goal is, and how they’ll achieve the goal.

Even as new, unexpected things pop up, the scrum framework made sure the scrum artifacts also evolve to represent the new reality. It could be either the development team uncovering a technical roadblock. Or it could be a shift in market condition (hello work from home!).

All of this is taken into consideration through scrum ceremonies with the help of a scrum board.

Each scrum artifact answers one primary question:

Product backlog : What should the team work on in the next sprint?

Sprint backlog : What should the scrum team work in the current sprint? How will they achieve it?

Product increment : What will they team ship at the end of the sprint?

The three agile artifacts ensure it breaks down large bodies of work into smaller, focussed work. This allows the scrum team to focus on the relevant work and ship the most important work.

The scrum artifacts together promote:

Scrum Values: commitment, courage, focus, openness, and respect

Pillars of Scrum: transparency, inspection, and adaptation
Minimizes unnecessary work

Let’s take a closer look at the function of each agile artifact.

Product backlog

The product backlog is practically a giant list of everything you’d want your team to build.

The product backlog includes new features, enhancements, bugs, and small tasks that need to be worked on to improve the product.

The work items (which are mostly either user stories or bugs) in the product backlog often comes as an input from the customers. Sometimes, depending on the organization, even team members add their inputs to the product backlog.

Of course, this means the product backlog will be an endless list. Unless you have an army of developers and designers on your payroll, you will not be able to build everything that’s on the product backlog. This is where the product owner will play an important role.

The product owner will be responsible for prioritizing the items in the backlog. By talking with the customers and internal stakeholders, the product owner collects feedback and data points to make data-backed decisions that will positively impact the product.

It is the product owner’s responsibility to keep in mind the business goals and the product roadmap while prioritizing the product backlog. Each item in the product backlog goes through what’s known as backlog grooming.

It looks like this:

Review each backlog item carefully.
Remove duplicate items and unwanted items.
Edit or rewrite the user stories based on the newly available information.
Add story points to each of the prioritized items. This usually isn’t an accurate estimate, since the developers usually have a better understanding of the complexities involved. That’s it’s always better to involve a developer during this process so that the estimates aren’t off by a large margin.
Add acceptance criteria for the prioritized list of items.

This product backlog will act as an input to the sprint planning meeting. This makes it critical that all of the above-mentioned steps must be done before the beginning of the next sprint’s sprint planning meeting.

During the sprint planning meeting, the product backlog is presented to the entire scrum team where the product owner describes each prioritized item in the product backlog. He/she shares why they are the highest priority and how it connects to the business goals and the roadmap.

From here, the sprint backlog is derived. Let’s look at it in detail.

Sprint Backlog

The second artifact in scrum is the sprint backlog. As I mentioned previously, your team will not be able to build everything added in the product backlog.

This is where the sprint backlog comes in.

The sprint backlog is the most fundamental part of the scrum sprint. It’s practically a filtered, prioritized version of the product backlog. The sprint backlog allows your team to focus on the most important work and commit to shipping it at the end of the sprint.

So, how does the team decide on the sprint backlog?

Once the product owner describes the product backlog and why it’s a priority during the sprint planning meeting, the development team will ask questions to understand the product backlog better. This helps the development team to come up with a more accurate estimation of how long each item would take to complete.

As you can see this is a collaborative effort by the entire scrum team. The product owner answers all questions the development team has. The scrum master facilitates the meeting. And the development team gives an estimate of what can or can not be done within the sprint duration.

Once the estimation points are added to all the items by the development team, the entire scrum team negotiates on what should be included in the scrum backlog.

It often looks like this:

After looking at the estimation points added by the development team, the product owner realizes that all prioritized items can not be built within the current sprint. This requires the product owner to make sacrifices.

Some product owners may try to squeeze a few items in, but the development team should push back and let the product owner understand that it will not be possible to build a shippable version by the end of the sprint.

This back-and-forth negotiation goes on until the team comes to a shared commitment on what will be shipped at the end of the sprint. Ultimately, the development team will own the sprint backlog since they’re the ones who will be working on them.

This makes it essential that the development team push back if they believe they can not deliver a shippable version at the end of the sprint.

If you're looking for differences between product backlog vs sprint backlog, you might be interested in this article.

Product Increment

The product increment is the output of the Sprint and the sprint backlog. Everything that was committed in the sprint backlog is delivered by the development team as an increment to the product.

The product increment should be a usable and potentially shippable version of the product.

This means the product increment should not require any more testing nor further development. It should ideally be in a position where if the scrum team wants, they can ship it to production for the customers to use the product.

In theory, it sounds simple. However, in practice, the scrum team must ensure everyone has a clear understanding of what the product increment will be at the end of the sprint.

A shared understanding of the definition of product increment sets the right expectations for the development team. It helps them estimate better and work with clarity. And once the sprint is completed, it can also help during sprint retrospectives.

If there is no shared understanding of what “done” looks like, the scrum team should make sure they have one before the sprint begins.

Other Scrum Artifacts

Earlier in this post, I mentioned some teams call burnup and burndown charts as a scrum artifact as well. Let’s look into them.

The burnup and burndown charts represent the quantity of work remaining in the sprint versus time remaining in the sprint.

The burndown chart shows the number of work items remaining while the burnup chart shows the number of items completed.
These agile metrics can be used to view the team’s progress, identify roadblocks during daily scrum meetings, unearth problems during sprint retrospectives.

Never disappoint customers: 3 essential rules to build better software features

Vikash Koushik — Thu, 16 Jul 2020 04:41:01 +0000

What is the desired outcome for a software product team?

Completing as many tickets as possible? Or shipping a feature that your customers want and move the needle for your business?

The answer, I’m sure, is the latter.

Today, more software updates are being shipped than ever before. Unfortunately, only a few have an impact.

Features you ship need to make an impact and be frequent enough to build relationships with hard-won customers.

That’s a lot riding on the quality of the software you ship. And not many teams realize that.

If you want to avoid underwhelming your customers, be sure to follow these three rules when building software features.

Rule 1: Building features is not about checking off tickets

It shouldn’t come as a surprise that building features aren’t about checking off tickets and tasks in your issue tracker. But you and I end up obsessing about it anyway. And get disappointed when the software you ship isn’t up to the mark!

It’s why 56% of managers are looking to switch their project management tool every year.

At Zepel, we don’t start by assigning tasks. Doing this gives each member only a disconnected piece of the entire feature. It’s the equivalent of micro-management.

Building with tickets and tasks gives your team only a disconnected piece of the feature.

We think software teams do their best work when they have the whole picture. And not with isolated tickets.

Instead of giving small isolated chunks, the team is given a feature document. It contains a detailed spec with user stories on what the feature should or shouldn’t do. That way, the team knows what the user is trying to accomplish with the feature.

From here, it is up to the team to decide how they build it. The developers and designers know the details and have all the information they need about what the feature should and shouldn't do. They're in better position to make the right decision.

After all, the development team is the one doing the real work.

A manager may come up with what looks like a solid plan with assigned tickets and issues.

However, it rarely matches the reality of software development.

Rule 2: Progress of the feature is more important than the task

Far too often we miss the forest for the trees.

On one end you have people obsessed at getting every pixel right. And on the other end, you have folks whose focus is shipping as quickly as possible.

*Our velocity chart is dropping. We need to find a way to ship faster!*

Both are dangerous. And they’re both a consequence of thinking in outputs instead of outcomes.

At Zepel, we look at building software features as a balancing act between the known and the unknown.

Work items in the known bucket are much more reliable. You’ve already figured them out or you have experience doing it. These are the ones you can ship quickly. The unknowns require more research and have questions that need to be answered.

The realities of software development is rarely straightforward. There are far more unknowns than knowns when you build software.

So, if the unknown work item isn’t going to move the needle and you’ve spent considerable time doing research, it’s important to keep it aside.

And when you’re faced with a situation where you can’t make a decision, ask yourself: what new information is needed to make a decision. If you’re unable to identify it, it’s best to move on.

It's normal to feel like you’re making a compromise at this point. A good approach is to ask yourself: is what you're building a step up for your customers from what they're used to? If the answer is yes, then you shouldn’t sweat too much about it.

Rule 3: People over processes and tools

It doesn’t matter if you’re following agile methodologies. It doesn’t matter if you’re using a sophisticated scrum tool or a kanban software. If your team members are unhappy, your processes and well thought out charts are as good as an air cooler in Antarctica.

Designers and developers want to do their best work. They care about having a consistent design language, great experience, and having a cohesive code base that covering all edge cases. They take pride in their work and that’s important.

The best development teams keep the broader purpose of the feature in mind while focusing on the finer details.

The reason why most teams aren't productive is because these processes are too rigid. They hinder them from gaining complete context for them to do their best work.

Instead of trying to fine-tune the process further, it helps to shift the focus towards people. In practice it looks like this:

Clarify goals frequently and realign people towards the goal: It’s easy to get caught up in completing a task and the finer details, forgetting the goal — ship a usable feature.
Set and reset expectations: Most of us set expectations at the beginning. But it’s equally important to reset them after a checkpoint. Every time you set and reset expectations, it’s an opportunity to reinforce and steer the team towards the goal.
Consistent check-ins: Check-ins do not only mean daily scrum meetings. Just asking a colleague if they need an outside perspective can go a long way in helping them do better work.

Product development: Focus on the result

Product development by its nature is different from issue tracking. People agree that the idea of building features by tracking one single ticket at a time is absurd. And yet, you still do it day-in and day-out.

This comes when you focus on outputs instead of outcomes. And when you’re limited by the tools you use. They make you put processes and tools over people.

There was a time when simply checking off tasks was all that mattered. It’s important. But in a demanding market with demanding customers, shoehorning developers into ticket-movers isn’t nearly enough to build solid products.

Instead, focus on the result. It enables you to think of the different ways to achieve the outcome and the multiple cases you would’ve missed had you spent time by thinking in tickets.

If you liked what you read, I think you'll love how we're re-thinking how project management tools and issue trackers should work at Zepel. Have a peek over here.

5 fun sprint retrospective ideas with templates

Vikash Koushik — Thu, 09 Jul 2020 09:14:25 +0000

The sprint retrospective is the most underestimated and under-utilized of all scrum ceremonies.

And I understand why that’s the case. Retrospecting requires you to be open and self-aware. It can be scary to do all that in front of your colleagues.

If you’re one such team, the below image should convince you to do more sprint retrospectives:

It shows where we end up if we look to improve by just 1% every day instead of when we regress by the same amount.

In this post I’ll share with you 5 sprint retrospective ideas with templates that you can use with your team today.

If you’re a small team that’s just getting started with scrum, you’re bound to see rapid improvements within your team.

However, if you’re a more mature team that’s been working together for a long time, you may not see rapid improvements. But it's important to not get disheartened by it.

As the above image shows, even a small improvement every day will go a long way in the long run.

Let’s jump in and look at the different templates and ideas you can use to run sprint retrospectives that helps your team to improve.

5 Sprint retrospective ideas

Idea 1: Car Brand

Use the car brand idea of running a sprint retrospective to relax your teammates. It’s one of the simplest, but effective way to identify problems within your team without making your team anxious or too serious. It helps your team to focus on the problem at hand instead of having them to point fingers at a specific person or their ideas.

How to run a Car Brand Retrospective

Gather your team in a conference call. Use a whiteboarding tool such as Miro to add post-it notes.
Ask your team to think back about the last sprint and how they felt about.
Now, get your team to describe it with a car brand name and get them to write it down on the post-it note. For example, if they feel it went smooth without any issues, they might want to describe it as a Ferrari. If they felt the team shipped some innovative stuff in the last sprint, they might call it as a Tesla. And if it went wrong, they might describe it as a second-hand car purchased from a shady car-sales guy.
To understand them better, ask your team to share their post-it note on your whiteboard tool and explain their perspective. You might be surprised at the different perspectives you get.
While the team shares their perspective, keep the metaphor to the car brand to avoid finger-pointing. If the second-hand car needs to be fixed, what are they? Is it related to speed, stability, or safety?
Repeat this process until every member has spoken.
Once everyone has shared their perspective, group the post-it notes under similar themes and vote on the top two or three brands.
The top car brands chosen (with what they represent metaphorically) will be the area of focus for the next sprint.

Idea 2: Mad, Sad, and Glad

The idea of using Mad, Sad, and Glad to run a sprint retrospective is perfect for your team if you want them to critically think about their feelings.

This template is used widely among teams primarily because it’s easy to get started. However, it might not be the best fit for your team if they are relatively inexperienced.

A good idea to use this template with inexperienced teams is to ensure the team has enough support and guidance. Because let’s be honest, critical thinking isn’t easy to master.

How to run a sprint retrospective using Mad, Sad, Glad idea

Gather the scrum team in a conference call. Make sure to use a tool where you can share sticky-notes. A good example of it is Miro.
Give each team member a few post-it notes and a pen.
Have three columns named Mad, Sad, and Glad on your Miro app.
Give your team 15 minutes to come up with three or four observations of the last sprint and write it down on the sticky note on Miro.
Once the time is up, each team member should place their sticky note under Mad, Sad, or Glad depending on which column best describes what they’ve written in the sticky note.
Ask each person to describe their observation. When describing, it is important to be mindful of not turning this into a blame game.
After everyone has shared their observation, the team will vote to determine the top three observations that will have the highest impact.
The top three observations are discussed with the team. The conversation should be focussed towards generating ideas on how the next sprint can be improved.

Idea 3: Sailboat

The sailboat template for running a sprint retrospective is one my favourites. It discusses the team’s vision and goals.

It makes it personal for the team by focusing on their goal instead of the company goal.

While it can sound counter-productive at first, with a little bit of guidance you’ll quickly see the team’s goal ultimately aligns with the company’s goals.

How to use the sailboat idea to run a sprint retrospective

Show your scrum team a picture of a sailboat that’s pushed towards the land by wind, withheld underwater by an anchor, and has a pile of rocks ahead.
Help your team understand that a sprint also has multiple variables that help speed up or slow down the process. The land is the goal your team is heading towards, the rocks are the risks they might face, the anchor is the one that’s slowing their progress, and the wind is propelling them forward.
Write down what the team’s vision or goal is. Ask the team to brainstorm on what is propelling them towards the goal, what’s holding them back, and what are the risks they see when trying to achieve the goal.
Have the team write it down on a sticky note. And when the time is up, ask each team member to explain their sticky note and group them.
Finally, choose what’s the most important risk and the most pressing issue that’s slowing them down. Address them together with the team. If you’re unable to agree on what the most important ones are, I recommend having a voting system.

Idea 4: Start, Stop, Continue

Start, stop, continue is the simplest template one can use to run a sprint retrospective. Each point generated is action-oriented and directly tied to a behaviour change.

How to use the Start, Stop, Continue idea to run a sprint retrospective

Show the team three columns labelled as Start, Stop, and Continue.
Ask them to reflect on three things:

a. What would they like the team to start doing? Examples of things the team would want to start doing could be things like doing code reviews more frequently and showing the prototype to customers early.

b. What would they like the team to stop doing? Example of things that the team might want to stop doing could be things like stop turning up late to the daily scrum standup.

c. What should the team continue doing? The continue list should have items the team would like to continue doing and place more emphasis on them because those items aren’t a natural habit yet.

Ask your team to share their responses on a sticky-note and share their reasonings. This will help the entire team get multiple perspectives on how they can improve themselves.
If there are several items for Start, Stop, and Continue list, then it might be better to vote on the top three items that can have the maximum impact. This will allow your team to focus instead of being all over the place.

Idea 5: The 4 L’s

The 4 L’s stand for Liked, Learned, Lacked, and Longed. It’s straightforward to implement, gets the team to open up on the things they can improve, and is effective.

How to use the 4 L template to run a sprint retrospective

Share with the team four columns labelled as Liked, Learned, Lacked, and Longed For.
Ask your team to write down:a. what they liked in the previous sprintb. what they learned from the previous sprintc. what the previous sprint lacked that hindered the team’s progressd. what the team longed for to be implemented or removed
Give the team enough time to brainstorm and write down their observations.
Once the team shares their observations, be sure to ask each member to share the reasoning.
Once everyone has shared their inputs, decide on what to change for the next few sprints. These can be identified by looking at the Lacked and Longed For columns.
The lacked column is the first thing you should look to address before jumping to the “longed for” column because the “longed for” column can sometimes have a list of “nice to haves”. And the “lacked” column specifically points out the things that the team believes is lacking for them to achieve their goals.

Conclusion

These five sprint retrospective templates should help you cycle through for several months. Be sure to use each idea for at least three consecutive sprints to see how your team is improving.

If you begin to see your team lose energy and enthusiasm, be sure to first show how much progress they’ve made in the last several sprints. As tempting as it may be, try not to switch between the different templates too soon or too often.

At Zepel, we keep our previous Sprint's burndown chart or burnup report open when discussing ideas during Sprint Retrospectives. This helps us to come up with better ideas on how we can improve ourselves as it gives everyone a complete perspective of what happened.

The goal of agile software development is to improve as a team. Remember, as the agile manifesto says, put people before processes and tools.

Have other fresh ideas on running a sprint retrospective? Tweet to us @GetZepel and we’d love to share your ideas with everyone.

How issue tracking hurts product development

Vikash Koushik — Wed, 01 Jul 2020 09:37:54 +0000

We published a new article on how issue tracking hurts product development. It got added on the Hacker News community and I thought you might enjoy it.

https://news.ycombinator.com/item?id=23699581

Are issue and ticket tracking tools hurting product development?

Vikash Koushik — Wed, 01 Jul 2020 09:14:25 +0000

The short answer is yes. Let me explain.

I’ve been working with developers and designers my entire life.

I’ve built a couple of products, worked at a young startup, and I’m now at Zepel helping development teams build better software.

I’ve spoken to 1000+ development teams while at Zepel alone. And it's evident that the way we build products is broken.

There’s so much disconnect between how you and I talk about building products and how our teams actually build them.

For all the talk of scrum and agile and getting feedback quickly, there’s so much that’s broken in how we act on the feedback and build the feature.

Teams spend so much time and effort getting a deeper understanding of customers’ needs. And yet distil everything down to a simple two-line ticket and a couple of lines of markdown description.

This is hurting your developers. And it’s hurting your business.

Nothing is more frustrating than having to understand what an entire feature should or shouldn’t do from a two-line ticket filled with ten bullet points of acceptance criteria.

*Here are five prioritized tickets for the upcoming sprint. We have to ship them on time!*

On the other hand, you have teams who are able to build top quality software. They’re the ones who can concentrate on the fine implementation details without losing focus on the broader purpose of the feature as a whole.

Everyone wants to get to that level. But instead, teams do the exact opposite.

Teams think in issues and tickets, instead of the feature as a system.

Development teams are not ticket movers!

Today, everything is about moving a ticket from “Todo” to “Done” as quick as possible. And watching burndown charts. And customizing the tool to the extent that the developer only views a single ticket.

*“What’s the velocity of our team?” is simply another way of asking how quickly can my team move an issue from “Todo” to “Done”.*

Pieces of that stuff are important for productivity and shipping on time.

But seriously, how is your team supposed to ship anything of value if you narrow their focus down to the smallest unit of work without any context of why it’s needed or how it connects to the whole feature?!

Overall, we’ve lost our way. Product development today has become more about checking items off a list as quickly as possible.

It isn’t enough to write multiple user stories and share a Figma link if you want to ship quality software.

How software product teams really build software together

Development teams build better software together when they have the complete context of what and why something is being built.

To achieve this, the foundational elements need to change.

And it starts with getting the right abstractions and naming conventions.

The names you choose determine the perception and the quality of conversations you have. It’s why top developers spend time obsessing over names for classes, functions, and variables.

When you open up a VS Code and see a function called send_signup_email, you have a certain sense of what’s going to be inside and why that’s there.

The right abstractions can drive the team towards asking the right questions. And this is critical.

Because when you’re tracking issues and tickets in isolation you have no choice but to measure only outputs.

And teams today don’t want to measure only the outputs. They want to measure outcomes.

What’s the right abstraction?

The right abstraction is the one that prioritizes people over processes and tools. It's the one you and I use every day — it's Features.

When a squad creates a Feature and opens it, they’ll get to look at the entire feature as a unit. A user story inside it might describe a specific functionality. But the difference is, now each developer and designer know how it connects to the larger scheme of things for the entire feature.

A feature forces inept managers to stop focussing on output-oriented questions like “how can we work faster”.

And shifts the focus on outcome-oriented questions like “why should we prioritize this feature” and “how does this feature tie to the OKR”.

Miscellaneous tasks and incoming bugs can be tracked on a separate “List”, so high-priority bugs don't get missed out. And of course, when it comes to tracking them, they can all be tracked on a Sprint or on a Kanban Board.

Feature as an abstraction is the right middle ground that lets you focus on the output as well as the outcome. It lets you zoom in and track what's happening today. It also allows you to zoom out and track a feature's progress across multiple disciplines. And it enables you to see how a feature moves from a feature request all the way to prioritization and development.

Simple issue trackers and project management tools have shoehorned teams into ticket-movers and have made them think in outputs. Metrics get feigned to show productivity. Thinking in outcomes has become ridiculously hard. And it's hurting businesses.

It's time for tools to reflect the reality of product development. It's time to remove the disconnect between development teams and what your customers really want.

It's time to stop thinking in isolated tickets and start thinking in features as a system!

If you liked what you read, I think you’ll love what we have in store for you. Go ahead and try Zepel for free.

5 Git workflows you can use to deliver better code and improve your development process

Vikash Koushik — Wed, 27 May 2020 13:15:54 +0000

I haven't met a developer who looked at a conflict message and did not pull their hair strands with frustration.

Trying to resolve each merge conflict is one of those things that every developer hates. Especially if it hits you when you're gearing up for a production deploy!

This is where having the right Git workflow set up can do a world of good for your development workflow.

Of course, having the right git workflow will not solve all your problems. But it's a step in the right direction. After all, with every team working remotely, the need to build features together without having your codebase getting disrupted is critical.

How you set it up depends on the project you're working on, the release schedules your team has, the size of the team, and more!

In this article, we’ll walk you through 5 different git workflows, their benefits, their cons, and when you should use them. Let’s jump in!

1. Basic Git Workflow

The most basic git workflow is the one where there is only one branch — the master branch. Developers commit directly into it and use it to deploy to the staging and production environment.

Basic Git Workflow with all commits getting added directly to master branch

This workflow isn’t usually recommended unless you’re working on a side project and you’re looking to get started quickly.

Since there is only one branch, there really is no process over here. This makes it effortless to get started with Git. However, some cons you need to keep in mind when using this workflow are:

Collaborating on code will lead to multiple conflicts.
Chances of shipping buggy software to production is higher.
Maintaining clean code is harder.

2. Git Feature Branch Workflow

The Git Feature Branch workflow becomes a must have when you have more than one developer working on the same codebase.

Imagine you have one developer who is working on a new feature. And another developer working on a second feature. Now, if both the developers work from the same branch and add commits to them, it would make the codebase a huge mess with plenty of conflicts.

Git workflow with feature branches

To avoid this, the two developers can create two separate branches from the master branch and work on their features individually. When they’re done with their feature, they can then merge their respective branch to the master branch, and deploy without having to wait for the second feature to be completed.

The Pros of using this workflow is, the git feature branch workflow allows you to collaborate on code without having to worry about code conflicts.

3. Git Feature Workflow with Develop Branch

This workflow is one of the more popular workflows among developer teams. It’s similar to the Git Feature Branch workflow with a develop branch that is added in parallel to the master branch.

In this workflow, the master branch always reflects a production-ready state. Whenever the team wants to deploy to production they deploy it from the master branch.

The develop branch reflects the state with the latest delivered development changes for the next release. Developers create branches from the develop branch and work on new features. Once the feature is ready, it is tested, merged with develop branch, tested with the develop branch’s code in case there was a prior merge, and then merged with master.

Git workflow with feature and develop branches

The advantage of this workflow is, it allows teams to consistently merge new features, test them in staging, and deploy to production. While maintaining code is easier, it can get a little tiresome for some teams since it can feel like going through a tedious process.

4. Gitflow Workflow

The gitflow workflow is very similar to the previous workflow we discussed combined with two other branches — the release branch and the hot-fix branch.

The hot-fix branch

The hot-fix branch is the only branch that is created from the master branch and directly merged to the master branch instead of the develop branch. It is used only when you have to quickly patch a production issue. An advantage of this branch is, it allows you to quickly deploy a production issue without disrupting others’ workflow or without having to wait for the next release cycle.

Once the fix is merged into the master branch and deployed, it should be merged into both develop and the current release branch. This is done to ensure that anyone who forks off develop to create a new feature branch has the latest code.

The release branch

The release branch is forked off of develop branch after the develop branch has all the features planned for the release merged into it successfully.

No code related to new features is added into the release branch. Only code that relates the release is added to the release branch. For example, documentation, bug fixes, and other tasks related to this release are added to this branch.

Once this branch is merged with master and deployed to production, it’s also merged back into the develop branch, so that when a new feature is forked off of develop, it has the latest code.

Gitflow workflow with hotfix and release branches

This workflow was first published and made popular by Vincent Driessen and since then it has been widely used by organizations that have a scheduled release cycle.

Since the git-flow is a wrapper around Git, you can install git-flow in your current repository. It's a straightforward process and it doesn't change anything in your repository other than creating branches for you.

To install on a Mac machine, execute brew install git-flow in your terminal.

To install on a Windows machine, you'll need to download and install the git-flow. After the installation is done, run the following Git Command git flow init to use it in your project.

5. Git Fork Workflow

The Fork workflow is popular among teams who use open-source software.

The flow usually looks like this:

The developer forks the open-source software’s official repository. A copy of this repository is created in their account.
The developer then clones the repository from their account to their local system.
A remote path for the official repository is added to the repository that is cloned to the local system.
The developer creates a new feature branch is created in their local system, makes changes, and commits them.
These changes along with the branch are pushed to the developer’s copy of the repository on their account.
A pull request from the branch is opened to the official repository.
The official repository’s manager checks the changes and approves the changes to get merged into the official repository.

Automating your Git Workflows for better productivity

One of the things that developers have to constantly juggle with is updating their project management tool to keep their teammates updated. That’s why, at Zepel, our developers automate their workflow, so they can spend more of their time building the software.

Here’s how we automate our git workflow to keep everyone in sync:

A simple flowchart of how developer workflow is automated with GitHub, Zepel, and Slack

While Zepel integrates deeply with GitHub, Bitbucket, and GitLab, we use GitHub internally. So, once we’ve integrated GitHub with Zepel, our development team sets up the git workflow automation within Zepel. Here’s how it looks today:

Automating Zepel to update statuses based on Git workflow.

As developers continue to make progress, our team automatically gets a Slack notification and their changes are recorded within the user story.

Real-time updates on every commit, pull request, and branch changes.

Your own workflow!

The git workflows I’ve shown in this article are examples of some of the popular and best working workflows for the development team. Some teams create a branch for Staging and it works perfectly for them.

If you use other workflows that work well for you, tweet to us @getzepel. We’d love to showcase them!

A simple software development workflow to build better products and features

Vikash Koushik — Tue, 21 Apr 2020 10:43:55 +0000

The need to improve the development workflow is on top of every software team’s mind.

“Is there a way to get my team to ship features faster? How to build features with fewer bugs?”

And since you’re reading this guide, I’m sure you’re asking these questions too!

What software development workflow looks like in most teams

For most teams, software development looks like this:

The product manager, along with customer-facing teams, spends time talking to existing customers and potential customers to understand about the market.

Depending on the business needs and customer requirements derived from the previous step, the product manager prioritizes features the team needs to focus on.

Using the information gathered, the prioritized features are spec’d with User Stories, Tasks, and Enhancements.

These actionable items are then shared with a cross-functional team to estimate, further prioritize, and then tracked using either Scrum or a Kanban to ship the feature within a deadline.

What software development looks like in most organizations

Looks pretty simple, right?

However, every step from market research to feature deploy has invisible inefficiencies within them. According to market research firm IDC, companies end up losing 20 to 30 percent in revenue every year due to inefficiencies. And that, of course, is a lot!

Seemingly small and invisible inefficiencies within your development workflow compound over time, cause a dip in productivity, and ultimately lead to unhappy customers.

Issues in your workflow may seem small at first, but without special attention, they add up, and become extremely apparent over time.

Over the past couple of years, we've built a collaborative workflow that brings together members from across functions and ship quality features and make customers happy. This guide will walk you through our development workflow and how we think about it at Zepel.

What causes inefficiencies in the software development workflow?

Because how can you improve your workflow if you don’t know what to improve upon in the first place?

Like many teams, we made the mistake of thinking, “Setting a workflow is about moving tasks and user stories from one column to another”. And boy, we couldn’t have been more wrong.

A software development workflow isn’t about moving cards from one column to another. It’s all the invisible flow of information too!

Let’s look at the 3 causes for a broken software development workflow:

1. Laser focussed on a specific task

In the last 10 years, far too many project management tools have been pushing the notion that you need to focus on just the things you care about.

Sure, that’s important. But software development isn’t just about checking off tasks. After all, the best developers are the ones who can focus on the fine implementation details while still having a picture of the broader purposes of the feature as a whole.

By being laser focussed on just the tasks assigned to themselves, development teams miss the forest for the trees.

The pyramid of development tracking needs

2. Greater emphasis on the process than productivity

While processes are great, we must understand they’re put in place to help your team stay productive and produce a desirable outcome. A mistake many teams make is overemphasizing teams to follow a process when it isn’t helping.

A good example of this can be seen when teams implement agile processes by the book in the hope of making their team agile. It’s important to keep in mind that processes need to be built with people in mind. And not with rules.

What good is a process if it hinders your team from being nimble and moving fast anyway?

3. Building complex, rigid workflows to get updates at every step

Workflows are simple when a team is small. As teams grow, the first thing that gets introduced is complexity. Developers and designers work in silos, without any awareness of what the other team was working on.

As each phase of the software development occurs in different tools and key pieces of information is lost when teams handoff.

To keep the development workflow in motion, you need a seamless hand-over between teams. And this needs to happen while each of them focuses on the task at hand without losing sight of the big picture.

A simple development workflow

Contrary to common misunderstanding, software development is a dynamic structure and is rarely static. A considerable effort is needed as new functionalities or constraints are added to the system.

This means, there are far too many moving parts to consider that simple task and issue tracking tools just don’t fall short.

The development workflow when building software needs to allow teams to achieve three things:

Get visibility at a specific task and the broader picture.
Reduce complexity by not having to set up configurations and stitched processes.
Reduce tools to streamline the process, so team members don’t have to be clueless about where to look for the most recent information.

The aim was to connect a deeper, connected workflow that allowed the team to do deep work by collaborating cross-functionally and get all the context they needed.

Naturally, we use Zepel to improve our development workflow and here’s how we did it. Let’s dive in and look at it step-by-step.

Eliminate ambiguity by creating alignment.

Delivering quality features at every interaction requires alignment from multiple teams and it shouldn’t be a passive process. At Zepel, everything starts with bringing everyone up to speed on the priorities. That means, sharing with the team on the features we need to be working on in the coming weeks and months.

Get a quick overview of the roadmap and track its progress

Based on the conversations our product team has with the customers and the business needs, the most important features are moved to the top of the todo column. A duration and an owner are set later on after the feature is spec’d and we have an estimate from the development team.

This gives every single member a complete picture of what our priorities are, even when things change due to unforeseen circumstances.

Think big, start small.

Once the top priority features are prioritized, the product manager jumps in to drill into the specifics of all the functionalities of the feature by writing detailed user stories, tasks, and enhancements. And how each functionality should behave by writing detailed acceptance criteria as descriptions.

A list of user stories, bugs, enhancements, tasks, and subtasks

We group and categorize user stories and tasks under Sections to make it easier to understand for anyone new whom we might collaborate.

This view makes it easy for the product manager to plan features. And gives them (and anyone who’s collaborated later on) a neat document-like view of what the feature is really about.

Putting an end to countless “What’s the update?”

After the feature is spec’d and all user stories are written, we plan and add prioritized items into the Sprint. By now, all the planning is complete and we're in the execution mode. At this stage, we assign specific user stories and tasks.

One thing we’re still learning and trying to understand is if it’s okay to add an item to a sprint after it has begun. There are tons of opinions on this one on the internet and we’re still figuring what works for us in this aspect. :)

Tracking the progress of a sprint

Since Zepel has a dedicated Sprint view, our team gets all the updates about that specific Sprint in one place — burndown charts, burnup charts, sprint overview, scrum board, and sprint backlog.

Before the Sprint begins, the development team makes sure they’ve configured Zepel’s GitHub integration. This allows them to just focus on their work, so they don’t have to come back to the app every time they need to provide an update.

Note: If you're not a GitHub user, Zepel also integrates with Bitbucket and GitLab.

Automating Zepel to update statuses based on Git development workflow.

As the Sprint progresses and the development team makes progress, our product person and engineering head can quickly open up specific items to see all their Git activity inside Zepel. This gives them a snapshot of the progress at a specific item.

Real-time updates on every commit, pull request, and branch changes.

Since we’ve already enabled Slack integration, every time a developer adds a commit, merges a branch, or opens a PR, statuses are automatically updated in Zepel and everyone is automatically notified through Slack.

A simple flowchart of how developer workflow is automated with GitHub, Zepel, and Slack

This gives our development team the freedom to work from within their code editor and GitHub, and not worry about updating progress.

Collaboration alone isn’t enough. Enable seamless handoff.

In software development, collaborating within a dev team isn’t enough. You need to be able to collaborate cross-functionally and hand-over information. This is critical because, without the right information and context, everyone will be working with different assumptions, leading to a delay in the feature release.

For small teams, this could be a single Kanban board with four or five statuses. In this case, the team composition is primarily the developers with probably one designer or a QA person in the mix.

However, if you’re a bigger team and have more members involved in building the feature, having a single board with ten status columns to accommodate every function will not be efficient.

To combat this, we add a board for each team. Like in any Kanban board, we move each user story from one column to another. Unlike other tools, Zepel also allows us to move a user story from one board to another when we want to collaborate cross-functionally.

This allows our designer to move a user story from Design board to Dev board’s Todo column once the designer has the final version of the design ready.

Adding a board for each team involved in the project

This is automatically reflected everywhere in the app, so everyone knows which board a user story is currently in and gives them a clear picture of what’s happening. This lets us see progress at a specific team and manage workload with filters without having to set up messy configurations.

A development workflow isn’t just about the columns in your Kanban board. It’s also about all the other details that get missed out in between the two columns.

As teams grow, there will be a lack of visibility in the day-to-day activities, additional communication overhead between teams will creep in, and general confusion around responsibilities will begin to come up.

An even bigger problem is being able to take all the micro-level progress from multiple teams and understanding how it impacts the progress at the feature level.

This workflow has allowed us to build complex features while staying nimble enough to fix major issues and address customer requests. Of course, this workflow is a work in progress. I hope this peek into our development workflow helps inspire you and your team to identify and streamline your workflow, so you can ship quality software all the time.

5 Acceptance Criteria Mistakes Teams Should Avoid

Vikash Koushik — Wed, 25 Mar 2020 05:00:01 +0000

Everyone wants to go Agile today. Teams want to put the user in the centre of their product development process while building products. After all, you are building the product for your users, right?

To do this, teams write user stories as a way to keep the user in mind while defining the product and its features. And to ensure the team meets the standards their users expect, teams write acceptance criteria for each user story.

It is easy for teams to neglect acceptance criteria as being simple.
However, they're used to document customer expectations, provide an end-user perspective, clarify requirements and prevent ambiguity. When done properly, this will eventually help your quality assurance verify if the development goals were met.

In this article I will talk about some of the common mistakes teams make when writing user stories.

1. They are too broad

Writing acceptance criteria too broadly defeats the fundamental purpose of its existence. While they should not be confused with test cases, acceptance criteria should communicate what specific conditions should be met to ensure that when a user story is completed, it meets a certain standard.

2. Does not consider the user experience

A good product is table stakes today. And that doesn't mean spewing features one after another, but building products and features that provides good experiences at every touch point. This makes user experience more important than what it was before.

If your acceptance criteria doesn't take into consideration the end-user experience, you're most likely missing out on a huge opportunity to satisfy your customers.

3. Writing about the "how" instead of the "what"

Yes, acceptance criteria should be specific and concise. But that shouldn't make you get too specific that you end up talking about the implementation details of how you're going to go about it.

Remember, at the end of the day, acceptance criteria are a set of criteria that needs to be satisfied. If they include "how" your team should implement a user story, you are in a way micromanaging them. By keeping things simple and talking about the "what", you give your team the opportunity to explore, get creative, and come up with solutions to solve the problem at hand.

4. Writing acceptance criteria as you build

Although acceptance criteria is usually written by the product owner, it can be written by anyone in the cross-functional team. Sometimes, I've noticed dev teams take this a bit too far by writing acceptance criteria while they're building the feature. The problem with this is, it doesn't keep other members aligned on this criteria and can lead to mismatch in expectations. It's essential for teams to ensure they write acceptance criteria before the sprint begins — ideally before the sprint planning meeting.

5. Having assumptions

It can feel silly to write an acceptance criteria that you think is kind of obvious. But what's obvious for you, need not necessarily make it obvious for your team. Building products and features is a cross-functional effort. That means, people come with different perspectives that others don't know. Writing even the most obvious acceptance criteria can help your team give the complete picture of what needs to be done and help remove inefficiencies in your development process.

Conclusion

Your agile tool might help you writing acceptance criteria with a template. But it is never as simple as completing a fill-in-the-blanks form.

The individual impact of inefficiencies in your product development process is almost always invisible. One mistake while writing an acceptance criteria often leads to a series of other mistakes. And the worst part is, it is nearly impossible to trace it back to a poorly written acceptance criteria.