Skip links

Product Playbook

Agile Development

What does “agile” mean?

An agile organization is characterized by the following manifesto:

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

The principles behind the Agile Manifesto can be found here:


For junior product managers, there is plenty of great literature around delivering world-class products through either SCRUM or KANBAN. The good ones are:

When setting up a new delivery team, all you need to do is:

  1. Decide on one of the two frameworks.
  2. Implement some core elements (such as sprint meetings).
  3. Continuously work with your team to improve and adapt the framework to your individual organization and people.

Do not just copy everything that literature or other sources suggest. In every organization product delivery is managed differently, from how tickets are written, over how meetings are conducted, on to how JIRA boards are used.

SCRUM nor KANBAN are “one-size-fits-all” solutions and different adaptations can work well depending on your organization, as long as obvious best practices (like doing dailies or retrospectives) are not completely ignored or done wrong.

In the end, achieving your goals and getting closer to your product vision matters, no matter how you get there.

Yet, to maximize the delivery output of your team, follow 2 principles:

  1. Run regular retrospectives to stop doing what is not working and start doing/testing new things. What works for your organization is better than what does not even if “literature” suggests differently.
  2. Create clarity and a shared understanding about your delivery processes for your team and other stakeholders. You can do that by implementing and maintaining an Agile Guide, i.e. a document that records how your delivery teams work on a day-to-day basis, which will help create alignment and effective collaboration within your team.

There is also a common misconception in the product world that SCRUM is “better” for building startup products than KANBAN. This is not necessarily true.

Again, both frameworks can work well for your team and specific product. Sometimes, it can also make sense to switch between both frameworks for a period of time.

Typically for high-maintenance or service-oriented products (e.g. a CRM system), KANBAN might be more suitable to use, while with clear scopes and predictable time horizons SCRUM has advantages.

Agile Guide

Here are some suggestions what information to add to your agile guide:

  • What meetings do we have? (dailies, plannings, grooming, retros, demo, …) Who is taking part? What’s the goal of each?
  • Do we work with SCRUM or KANBAN and why?
  • How are story points measured / what are our benchmark stories?
  • What are our past and current team velocities?
  • When is a ticket considered to be done?
  • How are tickets groomed?
  • How should a user story look like? When is it ready for implementation?
  • What happens with a ticket when QA notices a small bug related to this feature?
  • How do we deal with scope changes?
  • How do we deal with changed priorities during a sprint or quarter?
  • How do we maintain your backlog? How do we keep it small?
  • Who is allowed to create tickets?
  • How do we differentiate tickets for backend/frontend/business/QA?
  • How are tickets labeled?
  • How do teams commit to sprint goals and scopes?
  • How are releases done? How often do we release?
  • How do we handle urgent ad-hoc requests and maintenance without harming our quarterly goals?

Further Resources