The sizing in agile development is the ability to effectively calculate how long it will take to do a task. The skill to finish the task must be there. Multiple granular tasks can be rolled up into stories and epics. Eventually releases are cut. The granular tasks can be added up to whole project completion and accurate sizing. From sizing, project budgets are calculated. Taking a step back, effective agile development is a result of calculating sizing properly on projects. For example, I have a story to implement a user flow. With agile development, the whole team gets into a room and put the various tasks on the storyboard and cut note cards to directly write the tasks into tools like Jira and Greenhopper, which is an agile development tool. Many people can be part of an agile development sprint. The tasks are evenly distributed among the team, based on bandwidth.

While the sizing is being calculated, each participant in the sprint gives their estimates on how long it will take to complete their assigned tasks. The assigned tasks, with their sizing are rolled up into a release. Once the milestones of the release are calculated, then dates are given out to internal and external partners. What are the most effective ways to increase velocity of an agile development team? Velocity is the speed that you implement your agile development team execution. But first, mentor the team so they can reach optimal velocity. For that you have to teach the developer how to size their tasks, i.e. how long it takes them to do certain tasks. Once the developer gets used to the pattern, they can execute consecutive tasks. This becomes the velocity of the developer. Once multiple developers are trained, you can calculate the velocity of the team. To increase the velocity of the team, daily standups are essential. The developers start into a rhythm of execution where they feed off of each other. A good development team is very much like a good basketball team.

The focus needs to be there and management has to do everything to make sure that they have the path to execute their tasks in a timely manner. Once the team is in rhythm, they work themselves to reduce their distractions, because they don’t want to go into the standup meeting the next day and look silly by not accomplishing anything. There is a lot of pressure, but fun path, when the team is executing. It’s very easy to determine an odd ball in agile development. They bring no value, the team knows, they know themselves. Over time, either the team pushes them out, the management takes action or they themselves roll out. A good agile development team is competitive and they really dive themselves into product engineering.