Translate

Thursday, 18 May 2017

There is something about Scrum - 3

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

Productivity

Velocity, that your often hear trumpeted in Scrum, can be quite misleading. Velocity, in common terms, means distance traveled over time. But the distance needs point A from where the calculation of speed begins, and point B,
where the calculation ends.

Productivity needs two parameters, too - one, time (usually called planned or scheduled) and two, money (usually called budgeted or allocated) - and as in matters of relativity (!), needs a surface ie., resources (usually called resources allocated).

The below image depicts all the data that is needed to measure productivity.



But, the picture although tells a lot still does not bring to light the need to measure productivity ie., a platform from which future planning, additional productivity improvements steps can be taken.

And, we also have the assignment of the resource - two resources are assigned to a task at 60 and 50% respectively and the formula (G12+G13) that has calculated shows (in the top left of the below image) that both the values have been taken into account to calculate the planned date.



So what is missing?

Tuesday, 16 May 2017

There is something about Scrum - 2

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

But there is a way to ensure that you do not allow for crafty resource developers or managers or any smart alec from messing with your Sprint plan.

Like so.



Once you set the week of Sprint (2nd column from the left, highlighted with values 1,2,3,4 signifying the week), a Sprint team member will work on on a particular task, you can restrict any work done outside of the planned weeks for the task, as shown above.

Although the Work done will show 8 hours of work done but the effort remaining part will still show the remaining 2 hours because the work was done outside of week 1 - 4 !

And if you draw a productivity chart, per team member, as per their allocated hours on a project / product team then you can track the difference of 1 or 2 hour(s) that was done outside the plan!

But, of course, as long as it is done within the Sprint, it does not make much difference but it does help you put the 'corrupt' manipulators in place ! :)


#ScrumPlanner

Monday, 15 May 2017

There is something about Scrum...

...that makes me often think if there is no way that you can avoid corruption in the professional world because so bound is everything together that the more you try to resolve dependencies, the more they crop up in another form, in another aspect or place.

Ignoring Mr. Lingo-Nathan (a hideous rule-obsessed maniac), if a resource goes absent on the first day of a Sprint to the 7th day after the Sprint Backlog is planned (Mr. Lingo-Nathan would insist that the resource should not have gone on leave!), and a replacement resource is allocated the same work and the hours are billed as planned, how does it affect productivity, when we measure the effort of both Resource X and Y?

It is not a question that I pose but a preamble to manage Scrummers and Sprinters separately when doing Scrum.