Planning

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.

Sprint Planning

We have weekly Sprints. Every Thursday we close the previous Sprint and plan the next Sprint. Our team lead does quick Sprint planning:

• Creates a new Sprint in our Redmine system and moves uncompleted Stories from the last Sprint if there are any;
• Sets new Sprint size based on previous Sprint’s performance and team availability during next Sprint;
• Inspects Velocity of each team member’s last Sprint and discusses the main reasons for overperformance/underperformance;
• Fills Sprint by moving Stories one-by-one from the top of the backlog and collectively estimates the Sprint with the team;
• Schedules call with the Product Owner (usually client) for Sprint Retrospective and next Sprint Plan discussion.

Planning meeting takes around 10 mins.

User Stories

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.

Estimating

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:

• 0 - duplicate stories or already implemented features;
• 0.5 - basic change (e.g. add missing translations);
• 1 - very small change (includes test suite updates);
• 2 - small change (e.g. a very small feature or a fix which needs further investigation);
• 3 - medium change (a complex fix or a medium feature; for example, extending an already existing functionality);
• 5 - large change (e.g. when a story contains several requirements which require adding to a new functionality or extending an existing functionality);
• 8 - extra large change (e.g. usually a big feature - create new app entry points (controllers/API), create new resources, etc.);
• 13 - significant refactoring or a very complex change (e.g. something which requires making changes to the whole app);
• 20 - we tend to avoid such large stories by splitting them into smaller ones.

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.

Frequent Releases

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.