Koen about .Net

August 2, 2010

Experiences using SCRUM in project

Filed under: Projects — Tags: , — koenwillemse @ 18:20

The current project I’m working on is a pretty big project. I’m working in a team of 4 persons and we’re working on a Identity Management solution which is a small part of the project. The overall project is unfortunately not working in a SCRUM way. No product owners, no product backlogs etc. However, as team we have decided to do our work in a way in which we use as many SCRUM principles as possible.


So, how do we achieve this?
First of all, we have a very specific workload, which is not really linked to any of the other teams. This makes it a lot easier to get it working. So we defined our Product Backlog items and we estimated them.
But then, there was our first obstacle, since they had to be placed in a order of business value. So, since we don’t have a product owner, we ordered the items ourselves. Since it is clear what we have to do (a lot of stuff about the how is not clear, but that’s a whole other story ;-)) we could give them a pretty good order I guess.
So, we’re up and running. We’ll be having daily scrum meetings to keep everything in the team synchronized and the team lead attends the stand-up of the other teams to keep things synchronized with them.


We are using sprints of 2 weeks. We start the sprint with the planning sessions as we should. Even tough they aren’t always going exactly the way they should go according to SCRUM, eventually we get a sprint backlog and we can get starting.
We’re using TFS, so we have all our product and sprint backlog items registered. Next to that we also use post-it’s on large piece of brown paper to get a quick visual of the state of the sprint. Unfortunately it happens sometimes that people forget to update TFS according to the post-it’s or the other way around.
We also have a hand-drawn burn down chart, which contains both the burndown of completed work and the burndown on hours.

These few things together make it already a lot better to manage and keep an eye on the progress we’re making.

Excel sprint workbooks

Everybody who has worked with the agile template in TFS 2010 will probably have seen the iteration workbooks that are supplied. I really like those, since they provide a lot of information and insight. Unfortunately, for this project TFS 2008 is still used, so we don’t have access to those workbooks. I disliked that so much, that I started to create those workbooks which connect with the TFS2008 server. It actually wasn’t very difficult to get to what I wanted. I’ll try to write a blog post about this soon to show what I did and what I added to the sheets as extra information.


When looking at the burndown charts we have of the last sprints we have seen some interesting stuff. Here are the screenshots of the hours burndown of the last 3 sprints:

sprint 2 hours burndown sprint3_hour_burndown sprint4_hours_burndown

These burndown show a few things.

  1. The estimates in the second sprint (actually our third) were not very good. The yellow line (which is the total of estimates) has a few big gaps with the total hours.
  2. The last burndown chart has a big bump on it. What happened was that we missed some work when creating our sprint backlog and a few days later, several items were removed because some functionality should be different :(. The last part of the graph showed that we underestimated a few items. This had the effect that the total hours went up and the remaining hours almost stayed the same.
  3. A last point is that these charts look pretty good. All work was completed in time. However we didn’t do so well when looking at the work done burndown.

Let’s look at the work done burndown.

sprint2_work_burndown sprint3_work_burndown sprint4_work_burndown

So, what’s not good then?

  1. At several places, the graph of the work left is going up! This should not be the case. What were the causes?
    1. We didn’t do our sprint planning 2 very well, so we missed items which we had to do
    2. A few times, at the end of a day we noticed that an item that was ‘done’ actually wasn’t completely done
  2. The total of the charts is going up in the first two sprints. This was caused by the fact that our focus factor was a lot higher than we expected. We expected our average focus factor to be about 70%. We managed to get it at 80%-90% so we had more hours available then we thought. Next to that, we underestimated a few items.
  3. There are a few places where the remaining graph is going down pretty steep. This was caused by the fact that we didn’t review items as soon as development finished. We defined the following states for our items: Not Done, In Progress, On Hold, Ready for Test (Review), Done.
    It happened a few times that we were finishing the development of stuff, but instead of reviewing stuff that was ready for review, we just started on a new item. At some times we had 8 items which had to be reviewed / tested.

Conclusion & lessons learned

There are a few things we have to be aware of for the next sprints:

  1. We have to make sure that we keep our scrum-board on the wall (the big brown paper) in sync with what we have in TFS.
  2. We have to be more strict in the way we organize the sprint 2 planning session. We have to make sure that we identify all related tasks of a product backlog item. Next to that, we’ve learned more about the time that some type of tasks take, so we can make better estimates.
  3. Don’t look at just an hour burndown chart of a work burndown chart. Together, they provide a lot more information then just on their own.

We’ve learned a lot of the information we have gathered in the last three sprints and hopefully some of you find it interesting also.


June 11, 2009

Experiences with creating a Service Oriented Architecture

Filed under: Development, Projects — Tags: , , — koenwillemse @ 21:53

In May 2007 (yes a long time ago already ;-)) I started working for the customer I’m still working for. One of my collegues, Dennis Doomen, started here 2 months earlier with setting up a full SOA architecture for .Net as a POC. I joined him for supporting the internal employees by learning .Net (all previous Oracle developers) and also as a developer. When the project was in the acceptance phase, I became the Team leader when Dennis started working on a new project (for the same customer) and now I’m currently holding the position of architect for the systems build in .Net and the newly created front-end applications based upon the architecture.

In the past, the development for this company was fully based upon Oracle & Oracle Forms. They made a (small) shift by introducing a .Net web application for the external customers, which we have build. The new system was still largely Oracle (as database, but also Oracle Forms for the application for the internal users and unfortunately a lot of business logic). During the this period, TFS was introduced, which is now also being used for bug registration / tracking. Next to those initial application, more web applications have been created using .Net.

We created a Service Oriented Architecture based upon the following technologies: Web Service Software Factory (using WCF) for our backend logic, Web Client Software Factory for our front-end application(s), Enterprise Library Logging Application Block, Unity and the Enterprise Library Policy Injection as some of the base components. Next to that we also used open source components, like RhinoMocks and Nhibernate.

In the last 2 years we have run into issues, especially just after Go Live, and also during the development period. Looking back now, we made some good choices, but also some that are not so good. I’m going to try to post about some of the good choices (in my opinion) and about the bad choices and how we have fixed them or how we are planning to fix them. Hope I can help other people not to make the same less good choices and help them make better choices.

Create a free website or blog at WordPress.com.

%d bloggers like this: