⚡ Asana & Agile Guidelines

This page goes over how agile is used inside the Flowcontrol dev team. It also explains how Asana is used to manage the project progression, tasks, etc.

🚀 Our way of working agile

• Our way of working is a form of Agile. Due to our small dev team we created our own way of working that fits our needs.

• At the start of the working day each dev fills in their daily stand-up on Slack. These stand-ups are quite self-explanatory, but they’re a way to keep the team informed about what you’re working on, what you’ve done, and what you’re planning to do.

  📋 Questions

  • How do you feel today? — state if everything is okay or if you’re having a bad day.

  • What did you do since yesterday? - explain the steps you’ve taken since yesterday. Geek bot will state: this is what you did yesterday, but you HAVE to add more information than just; the same, continue doing it.

  • What will you do today? — explain the steps you hope to achieve today. Be explicit and not generic like; the same as yesterday, fixing a bug, picking up a new ticket.

  • Anything blocking your progress? - state if you’re blocked by something. This can be a technical issue, a question, or anything else.

  • ❌ An example of a bad standup:

  • ✅ An example of a good standup:

• Every 2 weeks we have a sprint planning. This is a meeting where we discuss what we’re going to do in the next 2 weeks. We create a list of tasks that need to be done and assign them to the devs. This meeting happens together with our PO (Rob).

• During this sprint planning we first take some time to look back at the last 2 weeks, what we achieved, learned, didn't go well and want to improve. This is called the retrospective.

📔 Asana

Asana is used as our project management tool. We use it to keep track of our tasks, bugs, and features. Asana is divided into six sections:

• In-progress: This is where all the tasks that are currently being worked on are stored. These tasks are assigned to a dev.
• Short term to-do: This is where all the tasks that need to be done in the next 2 weeks are stored. These tasks aren’t assigned to anyone yet. They are however, already defined and accompanied of a description detailing the task.
• Backlog: This is where all the tasks are stored. These tasks aren’t assigned to anyone yet. They are however, already defined and accompanied of a description detailing the task.
• Requests: This is where all the tasks that are requested by anyone are stored. They often need a proper description or an investigation if we’re interested in doing them.
• To validate: This is where some of the tasks that are done are stored. These specific tasks are considered done, but need some validation, either from another dev, user or the PO.
• Done: This is where all the tasks that are done are stored. These tasks are considered done and are closed.

When creating a new item, you have to decide how likely it is that we will pick it up. Is it a random new feature? Put it on the request list. If it's a bug, put it on the backlog. Ask yourself; what value does it bring?

📝 Note

When writing items on the backlog, ensure they have:

• An intuitive title
• A clear description
• Images / GIF / links that show issues/examples (if applicable)
• What needs to be done to complete the task