Playbook covers our best practices and gives you the best insight how we deliver successfull long-term software projects.
If you want predictability, you need planning. Good planning is essential for both our clients and us. Planning helps us to set weekly goals. It also gives the client a clear idea of when what they have requested will be delivered.
We have weekly Sprints. Every Thursday we close the previous Sprint and plan the next Sprint. Our team lead does quick Sprint planning:
Planning meeting takes around 10 mins.
We don’t usually receive complete specifications ahead of development. That’s good because full specifications can soon become out of sync once development has been started. Instead, we create User Stories as the project progresses. A User Story is a use case description, preferably from the perspective of a user. Some User Stories may be defined in other ways if this works better for a particular case. That’s ok as long as both the client and the team understand what needs to be implemented.
The User Story is set of changes that need to be performed in the current system in order to improve it for a user. This attitude helps us to welcome any amount of changes because the intention of every change is an improvement for the end user. Our entire process is designed for such change driven development.
There aren’t many restrictions on User Story content. The Product Owner can submit any type of content (description text, images with UI elements, prototypes, etc.). The only requirement is that the provided information should clearly describe the desired change so that the developers can implement it and testers can verify it.
We use Story Points to estimate Stories. We used to use an hour based system, but this never worked as well as Story Points. Developers are too optimistic and underestimate the time needed to complete the task, and this means that an hour based estimation never works. Developers, however, are considerably better at understanding a task’s scope and complexity. And it is for this reason that the Story Points system works much better.
We use a Point sequence that is similar to the Fibonacci sequence for Stories:
Most of the Stories are estimated during Sprint planning meetings. Planning Poker is used for collective estimation. Every team member individually estimates each Story one by one. Estimations for Stories are then discussed. Much of the attention is dedicated to analyzing why some team member has assigned considerably more or considerably fewer Points to a particular Story. The final amount of Story Points is assigned to Stories and saved in the Redmine planning system.
We also perform a quick Estimation meeting after our Daily Standup if some new tickets have been added to the current sprint. In such cases, we return Stories with the lowest priority back to the Backlog.
We deploy to the production environment multiple times each day. Client and users do not need to wait for new features until the end of the Sprint. This approach has benefits for both our users and our team. Users receive new features quickly. This also encourages us to maintain our software process at the highest level so that we can ensure fluent deployments multiple times a day.
There is also another important benefit here. We don’t need to plan releases. We simply deploy each new feature when it’s ready. This approach saves a lot of time and other resources.