A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

This is another post in a series of posts that talk about how to improve the Velocity of the team (read the last post on the same topic). In this post, I will mention a few points that can be focused on in terms of how to improve the Velocity of the team:
– Ensure that the backlog is maintained properly and visible to all the team members (and this includes both the Product Backlog and the Sprint Backlog). Ensuring that the Product Owner is keeping the Product Backlog updated with the backlog items ordered by priority (and putting this list up on walls and other places close to the team) ensures that the team is forever aware of the set of features that are going to come up in the future, and can already start thinking about some of those features (even if they do not actually start working on those features). Similarly, the Sprint Backlog needs to be regularly updated (the Sprint Backlog provides details of the tasks for a Sprint, including the tasks that are meant to be completed in the Sprint).
– Check out the team sizing. The recommended team size for a Scrum is between 5 to 9 members. If you setup Scrum teams that are more than these in terms of size, there are issues in terms of logistics. The Daily Scrum meeting gets more people, is more than just 15 minutes for the entire team, and gets people starting to feel that too much extraneous stuff happens in the meeting and maybe not worth attending. I have seen such things starting to happen, and seen how the communication process in teams (so critical to Scrum) start to become more difficult, with impacts on the functionality of the Scrum teams. Make sure that there is constant feedback from the team as to whether they are finding the Daily Scrum meetings useful, and worthwhile for them.
– Get advance planning done for the various features that are done as part of the Sprint backlog. For many features which are more complex, before the work can start for the engineering estimation and breakup, there needs to be some amount of discussion on what shape the feature can take. This is even more important when the features are complex or new, and there is no precedent of the features in other products (competitor products); in such cases the user story is not so easy to define. There needs to be pre-work done in advance so that enough of the design of the feature is done. What this typically means is that, in the Sprint before the feature is supposed to be detailed in User Stories, the User Design Specialists and the Product Owner need to spent some time preparing design, and if necessary, working with some elements of the engineering team to do prototyping and work through the architecture. This gives insight into some possible approaches in which the team can work; in a lot of cases, this advance work ensures that the team goes off in the right direction when it comes to actually breaking up the User Stories into tasks.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>