SCRUM - What todo when the Sprint Burndown Chart doesn't progress

So the Product Owner has listed the top priority items, the team has estimated how much they can do in a single Sprint, half way into a 3 week Sprint the Burndown Chart shows only 10developer days work out of estimated 30days work, what do you do now as a Team/Scrum Master?

At the morning Scrum meeting the ScrumMaster points out that only 10 out of the 30 days are complete, this is what the Sprint Burndown Chart is for, to visualise the problems early on.

If it ain't working then try something different.

Get some tasks complete by tomorrow's Scrum needs to be the goal.

Ask each team member what can be done to hurry along the completion of the items, something is holding up each developer, the developer must be honest and tell what the issue is could be;

I haven't been focussed

I'm being distracted by queries from outside the group

I've had other tasks to do (This is a common one, but then why isn't the task listed in the Sprint backlog?).

I don't understand this code , the code is uncommented.

etc.

The ScrumMaster must force an answer.

With the answer comes a potential solution. This could mean assigning help to the developer in trouble, the goal is to get tasks closed out soon and get the Burndown chart rolling, so reassign developers to help others, better to get 3 out of 6 task complete by tomorrow than to have 6 task incomplete in 2 days time.

Get some tasks complete by tomorrow's Scrum needs to be the goal.

SCRUM Task Estimation

Estimating the time to complete a User Story in SCRUM is done by the development team. I mean the whole development team and not just the individual developer. 

This is done using some sort of voting system which allows the development team to contribute their estimate for the User Story. One way to vote is to use a card voting system such as voting cards where each developer votes with a card, there's an online version of this at planningpoker.com. 

Whatever medium you choose to use doesn't really matter, the process should be the same, the User Story is studied and the team may later sit together and give their estimation time by voting,if the estimates differ greatly then the reasons why should be discussed. 

If a single value cannot be decided on and the estimate is larger than the time for the Sprint then a Spike is required or the User Story should be split into smaller User Stories.  

When voting on the estimates of User Stories the Fabbonici number should be used i.e. 1, 2, 3, 6, ............

if your Spring is only 3 weeks then the maximum estimate that can be given for a single User Story is 15days, any more than this and the User Story needs to be broken up or more research done in order to get a more realistic value.

SCRUM with Visual Studio

SCRUM addons and process templates are available for Visual Studio but of course there are prerequisites such as Team Foundation Server (TFS) which must be installed and in use.

3 of the options available are http://www.codeplex.com/VSTSScrum, http://www.scrumforteamsystem.com/ and eScrum.

These provide applications which help manage the SCRUM process more easily. 

1. I've had a quick look at the VSTSSCrum myself, the version I've looked at is Vs01 as my current project is running on Visual Studio 2005. To use go to the url above, http://www.codeplex.com/VSTSScrum, download version 1. The template itself must be installed on the machine running your TFS, see the Readme.txt in the unzipped files.After installation the of the process template on the server you'll also need to install another client template on the Client, again the Readme.txt explains this. I haven't used this yet. There's also a Project Connector available from codeplex, this might be handy, I think it is another layer for joining up Microsoft Project to TFS to Visual Studio.
2. The second option ScrumforTeamSystem is also a substantial application for managing the SCRUM process, In my case we're currently in Visual Studio 2005 so we're limited to using ScrumForTeamSystem v1.x, in their support forum it mentions an improved Client, ScumForTeamSystem v1.2. There's also a Blog which tells more on how to setup new projects at http://blogs.conchango.com/sfts/default.aspx.I've installed this, there are 2 installations required for this, one on you Server which is hosting TFS and the other on the client. The first installation installs the Process Template an makes it available to the project administrator to create new Projects with Scrum, after installation you'll see a new template exist in the Team Project Settings dialog, next time you create a new Team project this template will be available to you.
3. eScrum I haven't really tried, I downloaded the installer but unfortunately I could not find any documentation on eScrum, the installer is all that's available and this Blog did not speak favourable on the installation process hence I didn't bother installing.

Alternatively when you use TFS as you storage for your Project you can create your TFS project as an Agile project, "MSF for Agile Software Development", this is not really a full fit for the SCRUM process but it may do as an interim step to get you up and running quickly (it's what we have used ourselves), this gives you Task/Bug managment and Queries on the TFS system which you can use to create your Product Backlog but it's not ideal. It can be customised somewhat with "Customizing Work Item Types".I found the documentation on this topic lacking, first thing to note is that you must be logged in as a TFS Administrator to get the following options else they appear greyed out. There is a option within the "Team" menu name "Process Editor", in here you'll find options to edit Work Items or Bugs or the Process itself, the "Process Editor" is a graphical representation of the XML settings files that store the fields that appear in the various dialogs in TFS and constraints and actifities that are fired when a TFS user does something. These can all be customised and I suppose the Administrator could change the settings enough for the process to mimic SCRUM, I have tried a couple of things such as adding extra security contraints to certain actions, allowing and disallowing certain users from marking Bugs as Closed for example.

Visual Studio Team Foundation Server and Team Suite and Team System

The acronyms TFS and VSTS stand for Team Foundation Server and Visual Studio Team Suite or Visual Studio Team Server.

All of the above terms are regularly used to represent each other but this is incorrect. The terms are different, hears a brief explanaition below thanks to Dmytro Lapshyn :

People frequently say "VSTS" when they actually mean "TFS" and this creates some confusion. Use of VSTS to address both "Visual Studio Team Suite" and "Visual Studio Team System" also contributes to the confusion. To clear things up a bit:

• TFS - the server part of the suite that provides source control, build management and enables teamwork/ALM management
• Visual Studio Team Suite - the fullest edition of Visual Studio that includes team tools for developers, architects, testers, DB pros and a client license to TFS. Note that Team Explorer needs to be installed separately even though you have the CAL
• Visual Studio Team System - a more generic term for TFS plus Team Explorer plus Team Editions of Visual Studio

 

Now, on to process templates. TFS on the server side + Team Explorer on the client side is usually all you need to run any process template (however the versions of both TFS and Team Explorer do matter). Theoretically, you might need to install custom work item controls on the client machines, but again, the only prerequisite for this is having Team Explorer on the client.

So, in other words, you need neither the full-blown VSTS, nor a specific Team Edition of Visual Studio to use custom process templates. However, as you've said you're currently using TFS 2005, you'll be limited to v1.0 of http://www.codeplex.com/VSTSScrum template and you definitely need to double-check if TFS 2005 is at all supported by the http://www.scrumforteamsystem.com/ template. If possible, I suggest you upgraded to TFS 2008 SP1, Visual Studio 2008 Pro (which BTW now includes unit tests) and Team Explorer 2008 SP1. Again, no need to upgrade to VS 2008 Team Suite, though.

Agile Ideal Time

Ideal time is the time to complete a task, without taking into account other non-developer tasks such as email, meetings.
The total time taken (with the task + email + meetings +....) is known as the Elapsed Time (Real Time).

Ideal time is useful when actually trying to get a correct time estimation for tasks. If a developer gives an estimation of 2 days for a task then there are a few factors you must take into account.
First of all the 2 days is probably 2 Ideal Days, but this is not of much use if you do not know how much time the developer actually spends on the task (Ideal Time) and how much time they spend in total (Real Time). Lets say the developer has an Ideal Time/Real Time ratio of 1:3 meaning they spend one third of their time actually working on the task and two thirds of the time at meetings, email, browsing, lunch etc. Then you must multiply their 2 day estimate by this factor i.e. 2days x 3 = 6days. So know the Actual time for the task assuming their estimate was accurate is 6 days.
But you also must take into account that their estimate was inaccurate, you must use the Velocity value too, lets say the previous iteration took 30% longer than was estimated then you must multiple the Actual time by this factor as well , 6days x 1.3 = 8days.
So the estimated time of 2 days is now actually 8days.

Agile Work Unit

The "Work Unit" is a relative measurement of task time estimations against one another i.e. it's not an absolute time, e.g. Task 1 will take twice as long as Task 2.

The Work Unit is also used in combination with Velocity (I'm not exactly sure how?)
Task Estimation time = "Work Unit" x Velocity.

Agile Velocilty

The measurement of the time taken for the team to complete an iteration.

Velocity is used in combination with what are know as "Work Units" to give more accurate task time estimations.

This is a useful record as it allows one to measure the difference between the estimated time and the actual time it takes the team to actually do the work.
Using this value, you can adjust the estimates for future iterations and maybe projects as a whole.

E.g.
4 developers on your team including yourself.
5 iterations in a project release. Each iteration is 2 weeks (10 days ).
iteration 0:
You and your team estimate 5 features can be implemented.
At the end of the iteration only 4 of the features are completed, it takes another 3 days to complete the final feature.
The iteration has actually taken 13days in total therefore the Velocity is currently 13/10 = 1.3. Use this 1.3 as a multipation factor in the estimation for the next release.
iteration 1:
You and your team estimate 4 features can be implemented.
You imply your Velocity value from the previous iteration, 1.3.
To make the calculation easier you break the iteration into Developer-days i.e. 10days x 4 developers = 40developer days.
You imply your Velocity value, 40 x 1.3 = 52 developer-days. There's only 40 developer-days in a release so something must change, something must be cut.
You re-calculate, 4 features will take 52 d-days therefore 3 features will take 3/4s of that i.e. 39 d-days, perfect, so you cut one of the features. You now estimate there will be 3 features for this iteration.
Again at the end of this iteration you see that the 3 features only took 30 d-days, that's 30/40 so you can re-adjust the Velocity but this time in the opposite direction, 0.75.
Use this Velocity value of 0.75 as a factor when finding the real estimation for the next iteration.
etc etc