Agile for an IT Start-up – Part II


In the first part of the article, we covered the basics of Agile. In this part we will cover my way of Agile practices which is combined and modified version of Scrum & Kanban.

Let’s dive in.

Consider that you have to develop a software for a customer.

  1. Product Owner & Requirements & Backlog:
    1. One person can be assigned a role to be a product owner and he would be responsible for customer communication throughout the product life.
    2. Similar to traditional software development cycle, the very first thing would be to gather the requirements. But the difference is gather overall requirements for the product.
    3. Overall requirements will give fairly good idea about what the end product would be. Based on the requirements, discuss them with team and create list of Backlog items.
    4. One good practice would be to put detailed information of the requirements along with Acceptance Criteria.
    5. Collaborate with customers and continuously keep refining the list and details of backlog and done items.
  2. Development team:
    1. In Agile every team member is developer. The programmers, testers, designers all.
  3. Sprints & Sprint planning:
    1. Once initial backlog is created, collaborate with all team members.
    2. Priorities the features (backlog items)
    3. Timebox the sprint. i.e. depending on product size and backlog items, decide how much can be developed, tested and delivered within one single sprint.
    4. Divide each requirement into goals and team works to achieve that goal in one or two sprints.
    5. Create Epics and stories from Backlog and goals.
    6. Start assigning stories to developers based on developer and sprint’s capacity. Start with small and keep on increasing or decreasing the number of story assignments based on past sprints result.
  4. Execution:
    1. For preparing backlogs, creating Epics and Stories, Sprint planning and execution we need some tools. Most widely Agile feature used would be Agile Board.
    2. Agile board is simple visual representation of items (Stories) in different workflow states presented in swim lane fashion.
    3. Scrum:
      1. Simplest Agile board would be like TODO | In Progress | Testing | DONE.
      2. You can use a digital tool for this or just draw a board on whiteboard and use Sticky notes to represent your individual items (stories/bugs)
      3. So, when sprint is started all assigned items are put in TODO lane, each item is put in In progress when it’s being worked on, once done item is put into Testing, once Tested and delivered, item is moved to DONE.
    4. Kanban:
      1. The similar board can be configured if you wish to follow Kanban, and same board can be shared with customers to view. Once additional configuration that you can do is set to WIP (work in Progress) limit for each lane. WIP can be number of items, or Estimates or any other condition of your choice.
      2. For eg, we can keep number of items as WIP limit.
      3. WIP for TODO (10), WIP for In Progress (2), for testing (10), Done (10)
      4. As you can see that In-progress has WIP for 2, which would ensure that no developer can work on more than two items simultaneously.
      5. This would also give a clean picture of team’s capacity and availability.
    5. Daily Updates (Stand-ups):
      1. Everyday entire team should gather for 10 mins and share their updates with entire team. This is very important so do not skip on stand-ups.
      2. Updates can be what the person worked yesterday? What he’s planning to work today? What are the impediments if any?
      3. This gives entire team a daily progress; kind of a report and quick actions can be taken to resolve impediments immediately rather than at end of the sprint.
    6. Demo at sprint End:
      1. On the last day of sprint there should be a demo run with entire team (and customer if needed)
      2. Demonstrating implemented feature helps validating the implementation also it may uncover hidden things which are not planned or discussed yet.
      3. It gives opportunity to other team members to review and provide their inputs. Also product owner can get clear picture of the progress.
  5. Review, Improvise and Repeat (Iterate):
    1. At the end of each sprint collaborate with all team members and do a retrospective(review) of the sprint.
    2. First thing to check is Current work in progress and Done items. Based on the plan, ideally all items should be in Done. But if that is not the case, pending items goes to next sprint.
    3. TODO vs DONE items will give you better idea to plan next sprints.
    4. Another important thing to discuss and note: (First point of the Manifesto)
      1. What did we do well?
      2. What did not go well?
      3. What can be done better?
      4. Or simply put GOOD, SAD, MAD points.
    5. This considering above points continue doing good points, create action items for impediments and things that didn’t go well, and improvise the suggested things.
    6. Do a Sprint planning for new sprint based on above and start new sprint.
  6. Delivery:
    1. It is not necessary that you have to deliver after every sprint ends.
    2. There are many services that depend on other services which prevents the developed feature to be delivered.
    3. This is quite usual scenario and hence when we put the requirements in Backlog (Epics), we should divide the epics in stories such that working sub feature can be delivered after end of one or more sprints.
    4. After each delivery demonstrate the results to customer and get their feedback. This would help identifying and eliminating issues and changes requests. Also, customers would get a chance to decide whether any changes are required in final feature or product.

Once you start working in Agile fashion and keep improvising the execution, you’ll get great benefits.

Try to stick to the plan, keep happy and comfortable working environment which would ensure high throughput of team and happy customers.


Q: What are different roles we should have in a team?

A: There is no ideal list of roles for any team. As Agile suggest, team should be flexible and so should the Roles.

This flexibility also gives chance to each team member to take up different roles and responsibilities so as to increase their knowledge.

Some of the roles that I think should exist in role are:

    1. Product Owner: responsible for entire product and product level decisions  


  • Business Analyst (BA):


      1. Responsible for maintaining requirements and assisting in business decisions.
      2. Ensure everything is documented: Requirement along with Acceptance Criteria, Site Maps,
      3. Ensuring that Acceptance criteria is satisfied after every sprint end demo.


  • Designer / UX Designer:


      1. Designer and UX designer are different roles which can be assigned to one or more persons.
      2. Designer is responsible for visual of the product and UX designer is responsible for User Experience (Flows, Navigations, Clicks etc).


  • Programmer, Tester:


      1. In Agile all are developers, and in general scenario, developers are responsible for sanity and Unit testing as well.
      2. For regression and end to end testing it can be advantageous to have different person to test entire application.


  • Agile Lead/ Scrum Master:


    1. To help manage the project with Agile methodologies it’s good to have individual person to handle this role.
    2. Agile Lead or Scrum Master can be of different team or projects and they may server to multiple projects.
    3. Having different person from other team helps getting unbiased opinion and executions.
    4. Also, Sprint planning, Stand-ups, Retrospectives, Synchronising with other teams (Backend, Front end teams), Identifying impediments, creating Action items for them and follow-up to get them resolved etc. All these are challenging tasks. So better done by individual person.


To sum up, I would say, this is what my understanding and learning is. I use both scrum for execution and Kanban board for current progress tracking with WIP limits. I often serve as Product owner along with Business analyst or Programmer, Tester as well and for some projects I serve as Agile lead.

The tools available for Agile management also provides various other features like Sprint Reports, Burn-down Charts, issue tracking etc. which are great additional features proven to be useful for software development.


For detailed information, you can always refer to Wikipedia and other books.

Few references:


Thank you.

Agile for an IT Start-up


Before I start with the article, it is prudent to establish my credentials to write on this topic. I am Piyush Ramavat, CTO at Gyrix TechnoLabs. With 10 years of experience under my belt, I’ve worked with companies big and small on Services as well as Products. With 6+ years of experience in India, I have been working in Australia for last 4 years as a Senior Software Engineer.  I have used Waterfall, Agile and Hybrid Methodologies throughout my career and have expertise in driving them in a Start-up environment. That’s it about me.

Ideal Audience: This is a technical article and may not suit a beginner, it is better to have some understanding about Agile before going further.

Here are few links that may help:

So what is Agile ?

Agile management is known since 2001 and is applicable for all type of industries. Agile methodologies are very famous and quite dominant in the world of software development.

There are numerous practices like Scrum, Kanban etc. Each has their own pros and cons and here are numerous tools as well to digitally manage the projects.


The Manifesto for Agile Software Development

Individuals and interactions

Self-organization and motivation are important, as are interactions like co-location and pair programming.

Working software

Working software is more useful and welcome than just presenting documents to clients in meetings.

Customer collaboration

Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.

Responding to change

Agile methods are focused on quick responses to change and continuous development.

The Agile Manifesto is based on twelve principles

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly


Well, manifesto and principles look quite impressive and feels like if we follow them strictly we’ll be able to deliver great quality product; on continuous basis; on time.


Q: But how do we do that?

A: Firs thing Agile says is “being flexible”. There are many practices and methods available like Scrum and Kanban to manage and stick to above principles. So instead researching on all just use one that is already available and proven to be successful.

Q: We are a Start-up, we are inexperienced in Agile methodologies, we don’t have additional resources (Agile Lead / Scrum Master) to help drive our development. So how do we start being Agile team?

A: It’s simple, you do not need expertise in Agile practices. You just need enough knowledge about agile practices and software development.


Scrum: Scrum is an iterative and incremental agile software development framework for managing product development. It is a flexible, holistic product development strategy where development team works as a unit to reach a common goal. The key principle of Scrum is – It allows the customers to change their requirements. Working on goals rather than entire product helps achieve this quite effectively.

This also ensures that customer gets what they want and also prevents rework or change request efforts.


Kanban: Kanban is a method for managing “knowledge work” that balances demands for work with the available capacity for new work. Work items are visualized to give participants a view of progress and process, from task definition to customer delivery. Team members “pull” work as capacity permits, rather than work being “pushed” into the process when requested.

In software development, Kanban provides a visual process-management system which aids decision-making about what, when and how much to produce.

In short Kanban method shows the current work in progress, team’s capacity which allows everyone including customer to see current situation. It allows better planning and also prevents over committing.


Familiarise yourself with few agile terms

Backlog: Product requirements that are to be developed and delivered (Features, bug fixes, non-functional requirements etc)

Epics, Stories: Product backlogs are commonly written in Epic & story format. Epic represents requirements for one entire feature and stories are smaller sub features of which are part of Epics.

Sprints, Iterations: Sprint is timeboxed effort that is restricted to a specific duration (one week, two weeks). Sprints are repetitive hence iterations are commonly referred as sprints.

Hope, you’ve brushed up your understanding of Agile today. In the next article I will go in detail about my experience of implementing Agile in Startup environment.