Conchango have just released v2.2 of SFTS...

What’s new in version 2.2?

• New Engineering Practices reports:
  
  
• Build Code Churn
• Build Duration
• Build Files
• Build League
• Build Quality
• Build Static Analysis and Compile
• Build Unit Tests
• Builds
• Code Coverage
• Last Build Unit Test Results
  
  
• SharePoint Portal
  
  
• Installer now includes the fixes required to upgrade the SfTS 1.2 project portals
• "Reports List" Web part fixed to show report list when Team Project Name contains spaces
  
  
• ScrumforTeamSystem installed web site
  
  
• Changing a SBI state from (or to) “Deleted” now triggers the work remaining update.
• Now compatible with SfTS 1.x projects. The work remaining values in team projects created from version 1.2 of the SfTS template will continue to be updated.
• Now includes "Report Slide Show" web page (see below for more info)
• Changing the SBI links now triggers the State transition process.
• Added session state handler instruction to the “web.config” to override MOSS default setting.
  
  
• Process Template changes
  
  
• New SBI state transition added. Deferred -> Not Done.

Version One have recently published their in depth Agile survey which shows some obvious (to me at least) facts, but also some interesting areas, both fit for discussion.

The total number of respondents were, 3016 with 2319 surveys completed, spanning 80 different countries.

Firstly for me the statistics that I expected are as follows:

• Lack of up front planning being the highest concern about agile development (45%)
• Ability to change organizational culture is citied as the biggest barrier to agile adoption followed by a general resistance to change
• A matching statistic is the “company philosophy” is cited as the biggest reason for agile projects failing
• The most used agile tool is Excel :)
• Only 17% utilise agile on ALL of their projects.
• The most important reason for adopting agile is to “Accelerate time to market”, very closely followed by “Enhance ability to manage changing priorities”

Now the more interesting results, for me at least are…

Last Friday morning I presented a second Scrum talk on the topic of “Scrum: A hands-on look at Scrum for Team System.” at the Queensland VSTS user group. As usual there was a good turn out of people (for an 8am Friday morning start) and the presentation went pretty well, with lots of audience participation. Conversation was based mainly around estimating, story points and the product backlog and the dreaded talk of measuring actual time spent on tasks.

Measuring actual time spent on a Scrum task is a question that comes up often. In this session the comment was in relation to where in team system the actual time could be recorded? The answer surprisingly enough for a Scrum tool is nowhere (unless of course you add it yourself). I always like to dig deeper into the details of why people want to track actual time spent on a task, it normally comes down to two reasons :

1. To improve your own or the teams estimating skills. People believe that if they look at their estimate for a tasks and the actual then they will be able to improve their estimating.
2. A lack of trust between the line management and the team. The management want to know who is doing what and how long it is taking them.

Mind maps are a great tool for capturing brainstorming ideas. I dont intend to talk at great length here about how mind maps work as there are numerous articles on the net about mind maps and a good starting point is Wikipedia.

The interesting part for me was seeing these maps at work capturing user story requirements, which I have been doing for a few months now to great effect...

Are you having trouble with "noisey" chickens at your Scrum's? Then try one of these gadgets and chuck your chickens :)




They can really throw a chicken, my son manage to throw one of his chickens over 30 feet! ...

Im presenting this session at the Queensland VSTS user group session on Friday 3rd October.

Overview
In this session I will be introducing Conchango’s Scrum for Team System (SFTS) plug-in for tracking a Scrum project.
Tracking progress is an essential part of Scrum as is making this progress visible. We can use a number of tools to help automate this process however, we must remember that using a Scrum tool does not mean we are doing Scrum AND that Scrum requires no tools to run successfully.

With that said, SFTS can take some of the pain out of the administrative duties of the Scrum master for those that are using VSTS as their work item repository.

We will walk through creating a SFTS project, entering Sprint planning data, burning down a sprint and completing the release, and look at how SFTS automagically produces our Scrum artefacts such as the Sprint and Product Burndown charts.

Firstly, for those of you who don’t know what a Sprint Burndown is....

It is the chart that tracks available time in a sprint against the remaining work, as shown below. So we start at the beginning of the sprint at the top left hand side of the chart with all the work remaining (we haven’t done anything yet) and all the hours of the sprint available. We then progress towards the right (time) and downwards (completing work) until we hit zero, hopefully on or before the end of the sprint.

I submitted my application form to become a CSP a while back and received an email from the Scrum Alliance informing me I had passed and was now a CSP......