Bucketing and its value

[vc_row][vc_column][vc_column_text]Bucketing is a process during the weighting of stories that aids in improving the relative baseline from which to measure the amount / complexity of the work to be done.

One of the challenges that we faced during the implementation of Scrum was the accuracy of weighting. The typical velocity chart would look as follows[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_line_chart x_values=”Sprint 1; Sprint 2; Sprint 3; Sprint 4; Sprint 5″ values=”%5B%7B%22title%22%3A%22Planned%22%2C%22y_values%22%3A%2238%3B22%3B56%3B38%3B12%22%2C%22color%22%3A%22grey%22%7D%2C%7B%22title%22%3A%22Actual%22%2C%22y_values%22%3A%2245%3B38%3B30%3B35%3B22%22%2C%22color%22%3A%22sky%22%7D%5D”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]After implementing bucketing in the weighting process for a few sprints, the velocity chart looked a bit different. We obtained a much more accurate view of true velocity.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_line_chart x_values=”Sprint 1; Sprint 2; Sprint 3; Sprint 4;Sprint 5″ values=”%5B%7B%22title%22%3A%22Planned%22%2C%22y_values%22%3A%2232%3B24%3B66%3B28%3B28%22%2C%22color%22%3A%22grey%22%7D%2C%7B%22title%22%3A%22Actual%22%2C%22y_values%22%3A%2229%3B24%3B68%3B25%3B29%22%2C%22color%22%3A%22sky%22%7D%5D” title=”Velocity Graph”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]As can be seen, the influence of bucketing was quite significant. For us, the challenge in weighting has always been getting a proper baseline from which relative weighting could be done. Bucketing helped us with this. By comparing weights, the team members could calibrate on what a specific weight means to them. Building a CRUD for example, would be a [1] and that would become a relative baseline for the rest of the weighting.

We use Fibonacci for our weighting. We usually try to obtain enough clarity during the kickoff meeting, to ensure that we do not have stories with a weight larger than [5]. Stories with a weight less than [5] have enough clarity and transparency to accurately predict the complexity / amount of work needed to complete the story. Stories with a weight larger than five, becomes vague with many unknowns.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_line_chart type=”line” x_values=”0;1;2;3;4;5″ values=”%5B%7B%22title%22%3A%22Fibonacci%22%2C%22y_values%22%3A%220%3B1%3B2%3B3%3B5%3B8%22%2C%22color%22%3A%22blue%22%7D%5D” animation=”easeOutElastic”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

How we do bucketing

For us, bucketing is most useful when done after initial weighting. Based on previous sprints we have a very good ‘feel’ for what a specific weighting means. The developers can quite easily agree on what a [1] entails. After all stories have been weighted, the backlog is evaluated for a last time.

We create ‘buckets’ containing stories with each of the relevant weightings (Fibonacci). This enables us to evaluate whether a story weighted as a [1] entails just as much work as another story that was weighted a [1]. This comparison is done for each story. The weight is adjusted if needed and we end up with a more accurately weighted backlog and velocity measurement. To see the impact, refer to the previous Velocity chart.

As mentioned previously, it is important to at least have insight into what a [1] means and what a [5] means for each team. Ideally the implication [Complexity / Amount of work] per weight should converge across teams. This will aid in the comparison of the Velocity of the teams.

The INVEST criteria that was described here helped us a lot in the process of gaining mutual understanding within the team.[/vc_column_text][/vc_column][/vc_row]