I've been trying to learn git and I've decided that the next way to really get famliar with it is to use it with one of the teams I am on. They are using svn, so I have used git-svn to create the the mapper between the two. I wrote up a cheat sheet for myself with git flow I want to use and the reference links I used. If anyone can recommend any improvements let me know.

I just finished reading the book User Stories Applied by Mike Cohen. Its a great introduction to writing user stories and applying them to an agile environment.

The book is broken into 4 main sections. The first section titles 'Getting started', it introduces the reader to the process of writing stories. I found this really useful. The only thing I did not like was that there was not enough detail of showing how to write a story in the BDD style of AS... I WANT TO... SO THAT, as well as writing acceptance tests/scenario's in the GIVEN... WHEN... THEN... The BDD style of writing a story makes it easy for someone new to stories to write good and useful stories very quickly. It also helps with the implementation and testing of the stories.

The book then goes on to explain 'estimating and planning with stories' and 'frequently discussed topics of stories'. Both of these sections are useful, if not common knowledge to most agilists.

The The final section is a real gem and puts everything into context, Mike goes through an example of planning a project and iterations with user stories. This nicely details the process of creating user roles and writing stories for them. It also shows the process of prioritizing stories and planning a release. This should help any inexperience reader to get started and give new ideas to any experienced agilist.

I recommend anyone who wants to improve their user story writing or wants to learn how to write stories. Its a fantastic starting point and will help you get comfortable with writing stories.

I attached my mindmap of the book. I've only mapped the points I thought were relevant for myself but hopefully they are helpful for you too.

Its taken me a couple days or maybe even a week, but here is my mind map from the certified scrum master. I didn't include everything that was spoken about just the key points I found very relevant.

To Zoom in open image in another tab...

I'm currently on the certified scrum master training course run by Peter Hundermark of Scrum Sense. It's a two day training course discussing the basic principles of scrum. It's main focus was on the roles of the key players, specifically the role of the scrum master. Day 1 was very interesting, we started out by listing questions we have about scrum and outcomes we would like to get from the course. This was an interesting section and highlighted many concerns and misconceptions around scrum. Peter is an excellent instructor and has some great teaching methods. He constantly keeps everyone involved and helps guide people to the solution rather then telling everyone the answer to any of his questions and tasks.

The topics covered for day one where: Agile principles; roles and responsibilities and meetings. What I have take from the course so far is how important it is to define the roles of the players in the team. Also how important it is to get the team to buy in on the agile principles specifically trust and communication. We also briefly touched on how incentives for individuals don't work when they are in a team. The power of self organizing can never be underestimated.

On a side note from discussions with the other participants it was a gentle reminder of how many people are trying to implement agile principles but are finding it very difficult. I really think the best way to get a team running properly using scrum or any other agile methodology is with an external coach to help them. This will definitely help them get over the initial hurdles and get the team in the correct habits and disciples. I'm looking forward to day two tomorrow. I'll blog again on what happens and give my overall thoughts on the next day.

I've finally started my first open source project. In the Agile team I am currently working with, I found I needed a simple metric tool to analyze our code and give some simple code metrics to help the team.

The team was using code coverage as our only metric. Code coverage is a very crude tool to determine the quality of our tests. I wanted some more metrics to help us analyze our code to determine the quality of the code being written. We have as a team set certain standards which must be met for each class being written. Two of these is the lines of code per method and the complexity of the method. I initially looked at Ndepend , which is a fantastic tool, to help us measure these, but Ndepend is more complex then what we required. 

From these humble beginning DrivenMetrics was born. DrivenMetrics is a very simple metrics tool that can analyze an assembly to determine the number of lines in a method and the cyclomatic complexity (number of different branches) of a method.

When I set out to write this library I had some simple goals. I wanted to do TDD, I wanted to use Mono.Cecil to learn a bit about it along with ILasm and I wanted to write a console app with some decent commands like any *nix command line tool. I also wanted a good excuse to use github and get a feel for git and then hopefully eventually be cool like all the other cool kids using github :-)

The library works by using Mono.Cecil to disassemble the a .net assembly and then using Mono.Cecil.Pdb to load all the debugging symbols. The two metrics are then run to analyze the code, the results are then written to an html report. The tool is still very much in its infancy and any help from the greater community would be appreciated. To build the code use rake, I have not used albacore or rake.net as my build library but rather the simple BuildUtils.rb from Jeremy Miller's StoryTeller.

I would appreciate any feedback anyone is willing to give. I have a Todo.txt with things I would later like to add to the project. The source code is available on github at: www.github.com/garrensmith/Drivenmetric