Published in

Put your points in Agility

What is this thing called Agile?


Who doesn’t know about agility? It has become such a common stats in games such as RPGs as the main stats for ranger, thief, and so on. Well, outside the context of games, the term agile is also used in the context of software development. Here at, we are building tools to help you with agile software development, of course in the development, we utilize this so-called agile software development too.

A bit of history

In the early days of software development, software projects is often developed using a model called the Waterfall Model. It can be described as a series of phases or steps. The requirements are gathered up front, then the team went to design phases, then implementation, verification, and so on until the software usable. The catch is, once you go down the waterfall, you can’t go back.

Well, the Waterfall Model is not bad, of course. Some established companies is still using it. This model is good when the requirements can be gathered up front and the scope can be set before the design. But in reality some, if not most, projects are not like this. The requirements are changing and the software need to adapt to these changing requirements. Sometimes you need to verify if what you’re building is what your market wants, and you need to pivot in the middle of the development.

From this need, some other development methodologies were introduced, like spiral, incremental, unified process, and so on and so forth. But we’re interested in the specific development methodologies called Agile. In 200,1 a group of people got together and thought out their opinion to solve this problem, thus born the thing we call today as the Agile Manifesto.

The Agile Manifesto and its principles

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan


Let’s see its principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The many flavours of Agile

Just like GNU/Linux and their distros, implementing these so-called agile methodology is not a single, absolute, model on developing your product. It came with many flavours like Scrum, Extreme Programming (XP), and Kanban. These group of Software Development Process all implements the Agile Manifesto.

But as we’re building, you can already guessed it, we use Scrum and are building tools to help others with their Scrum process.


The Scrum Process (source: Wikipedia)

Let’s talk about Scrum in the context of, the intelligent scrum bot we are making.

Before we dive into the workflow of a Scrum, some terminologies:

A sprint is the basic unit of development in Scrum. Sprint is a duration in which the development took place. In the end of sprint, it results in a working increment of the software that can be tested and verified to the stakeholders;.

A product backlog is the whole requirement for their product that was planned before the first sprint, usually in the form of user stories, which is a fancy term for simple feature as seen by the user. These logs, user stories, and tasks are contained in the Scrum board (think of it like Kanban board, or well, Trello).

Sprint Planning

At the beginning of the sprint, the team holds this event called Sprint Planning. Basically, the team agree on the scope of the work they’ll be doing in the sprint duration (in our development, the duration of sprint is one month). Then they will select some items from the product backlog that will be done in this sprint. These selected product backlog are then put into the sprint backlog and sharded into small, specific tasks in the sprint board.

Daily Scrum

After sprint planning, the development team will then choose which task they will be doing and report their progress and blocker in the daily event called daily scrum meeting (in our software development project course, it’s not really daily but twice a week). Then the team will update the scrum board to reflects the progress.

Sprint Review and Retrospective

Our Burndown Chart for Sprint 1

In the end of the allocated duration of the sprint, the team will hold this two events, Sprint Review and Sprint Retrospective.

At the sprint review, the team will review their work, present the completed work to the stakeholders, and collaborate with the stakeholders on what backlog is accepted, rejected, or need revision, and also what to do in the next sprint.

Then in the sprint retrospective, the team will reflects on the past sprint, identify and agree on things to improve and how, and also evaluate the team itself. This resulted in continuous improvement of the team as a Scrum team.


While the Waterfall Model are fine for some projects, Agile is more suited to most project where the requirements could change anytime. At, we implement Scrum and are building tools to integrate with other Scrum team workflow.

We strived to help the scrum team with moderating the above three workflow of scrum with our bot. We have completed our first sprint, released the first increment of our bot, and learned a lot in the process. We hope we can improve it and help scrum team like us with their workflow.




A Scrum Bot project on top of

Recommended from Medium

Construct week project at Masai School Orbitz Clone

Coupling in Microservices, Part 2: Single vs. Multi-Repo

How to get started with Property-based Testing in C#

Qubed, or Q3

Breaking the Type System in Golang (aka dynamic types)

I Commit Myself to Backend Developer and Here’s Why

Auth using AWS Amplify In Flutter

Interviewing as a Junior Web Developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rakha Kanz Kautsar

Rakha Kanz Kautsar

React Native developer excited about performance and system designs.

More from Medium

Scrum sprints and Scrum roles

Is your team following Agile correctly?

Improving Sprint Predictability in Agile Scrum

The Dynamics of Story Points