Sprints


In our company sprints refer to two things - daily work sprints and developer sprints.

Daily work sprints allow each member of team to focus on current task.

45 minutes of sprint falls for every hour. It is a holy time when nobody can disturb anybody. So if you join to our team, know that during the sprint you will be able completely focus on the code and nobody will be able to bother you - neither the leader of your project, nor company CEO, nor even Pope Francis.

The remaining 15 minutes are a sprint break. However, it is not a break from work. Then we work normally, but it is time when you can come to the colleague and ask some questions (what is impossible during the sprint).

The only exception to this sprint rule is so-called “fire” - it is a crisis situation requiring urgent reaction (such as a server failure).

Developer sprints last for 2 weeks. This is the time when individual teams have to complete accomplishment of the new version our products.

Every two weeks on Monday there is “Release day” - a day when all projects release their updates.

Before beginning of each sprint the team has to verify designed tasks and estimates whether their performance is viable within the set time frame. If all members of team accept that sprint, then it is officially started and a team leader oversees that the plan is implemented according to the assumptions.

If during the sprint it turns out that the team has completed its task earlier - the starts the tasks set for the next sprint. In the same way, if some team has not made it on time - then the tasks are moved to the next sprint.

After each sprint is an evaluation - the exchange of feedback between programmers, team leaders and me (or my partner). We evaluate past sprint and wonder what can be improved in the next one.

In case of dynamic projects (i.e. those where the chance of appearance of unexpected variables is high) "To Do" section is divided to 3 subsection:

  • Sprint - task to do next week
  • High priority - task to do as a priority in the next sprint
  • Low priority - task to do when the section "High priority" is already empty
See picture enlarged

To show this with specific example:

April 2 (Monday)

  • At 10 a.m. we release update implemented in previous sprint
  • We evaluate the previous sprint
  • The programmers value the task from the new sprint and after some modification they accept it
  • We officially begin the new sprint

April 11 (Wednesday)

  • The project leader creates ChangLog - a document with all changes and new features introduced in the update.
  • The project leader passes ChangLog to the marketing team.
  • On the basis of ChangeLog the marketing team prepares marketing and information campaigns
  • The programmers team starts testing update they have prepared

April 12 (Tuesday)

  • Update tests are underway till the end of the day
  • In an emergency situation the team leader inform me or Dawid about problems and possible postponement
  • If everything went according to the plan - tests are officially closed.

April 13 (Friday)

  • The preparation for the Monday update is completed and its final approval.

April 16 (Monday)

  • Release day
  • Evaluation
  • Valuation
  • New sprint

Previous post Next post

Spreed the word: Add comment
About author
Author avatar
Michal Szymanski

Co-founder of MDBootstrap and BrandFlow. Entrepreneur, web developer, UI / UX designer, marketer. Dancer and nerd at the same time.

Leave a reply

Sign up to follow your progress and get additional benefits