CSP Completed

Happy to share that I have completed my CSP . I t took four months to provide the evidences to Scrum alliances.
I presented a series of  tech talk  webex session  to NA associates which was really helpful to provide evidences to this certification.
It is important to have CSR activities like serving as a volunteer.
This certification also helped to put together my Scrum / Agile activities comprehensively.
Already sharing my certification experience with friends.

Velocity and support- maintenance projects.

I observed that the velocity in a support and maintenance project doesn’t go up as it happens in the development projects. Instead, after identifying its normalized capacity it generally stays on there.

However, it is true that the number of stories supported or value delivered increases over a period of time as team gathers more knowledge on technical/functional areas.

This is because,

·As the team gets more expertise on support incidents, they start to size the effort with less story points. For example a support activity that was sized to be 10 story points will be sized to be 5 after 3 months and 3 after 5 months. I can see this happening.

·The knowledge earned enables the team to repeat the support activity quickly and deliver more.

·However, as they understand the issue earlier, they tend to size the repeating activity with less story points.

Whereas, development projects don’t repeat the activity. Event the reusable components are planned with less story points. So the velocity in development projects generally goes up as the team gets more expertise.

Fixing the ToDo issue in Burndown chart

One of the most common mistakes a normalizing scrum team would do is – to neglect reducing the Todo.

It is important that the team would reduce Todo as they make progress in a sprint. This enables scrum master and product owner (and hence stake holders) to understand if the sprint is making progress or not.

We can monitor progress – status, using a burn down chart. Burndown should grow downwards (in a 45 degree slide) along with ideal line when team makes the estimated progress. It will start grow in a straight line, parallel to X coordinate (Time) when team misses to make progress. Sometimes, some delivering / progressing team also get flat line burndown as they miss to reduce ‘ToDo’.

So, it is an important task to a Scrum master (as an owner of monitoring role) to give feedback to team on this. But how to identify the tasks (or stories) where ToDo is not entered? Here is how:

Get the backlog (Of course, sprint backlog), and check for the following.

• Identify all the stories that are done, but still having ToDo remaining.
• Identify all the stories whose tasks are completed but the ToDo is not reset to zero.
• Most importantly, find all the stories where the ToDo and the estimated hours are same but the Done hours are entered.

Give this list of Taks, stories to your team asking to check if they can reset or reduce the ToDo, which will immediately reflect in better Burndown and hence will be projected as a delivering team.