Urban Turtle's blog

Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.

Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome!

Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft.

My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog.

Mathieu: Sure, I will suggest him that but I think he also wants to track cost.

Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.

When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.

Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)

And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period.

The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”.

I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog.

The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period.

My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final

Cheers,
~françois

In the past, we’ve made claims that Urban Turtle supports virtually any process template. Therefore it came as a surprise to some people when our team said that building support for the new TFS Scrum template from Microsoft would take almost an entire two-week sprint. I’d like to take some time to tell you what we think means to be template-independent and how it differs from building true support for a process template.

Supporting MSF Agile 5.0
Urban Turtle 3.0 shipped with built-in support for MSF Agile 5.0 out of the box. We obviously assume most people using Urban Turtle have chosen this template because of this build in support. This template made it a challenge for us to implement a three-column task board because work items only have one Active state. Items are either active or they’re resolved or closed. Back then, we decided to use the AssignedTo field to determine where the work item should appear when it is active. An unassigned and active task should show up in the To Do column while an assigned and still active task would appear in the In Progress column. It made sense to us as we’re Scrum practitioners and we believe tasks should be unassigned until someone actually starts working on them.

While implementing support for MSF Agile 5.0, we made sure to externalize everything that seemed template-specific, like the state mapping for the task board columns or the stack rank (backlog priority) field. We then claimed to be template-independent, but some assumptions would later turn out to be wrong.

False Assumptions
When Microsoft announced the beta release of their TFS Scrum 1.0 process template, we figured we could quickly create a new mapping file to add support for it. We began analyzing the new template and we realized we couldn’t do it without touching the code base. Honestly, it would have been as easy as we thought but the decision by the Microsoft team, to stay true to the Scrum terminology, turned out to be a blocker for us.

When working on the initial release of  Urban Turtle 3.0, we made the assumption that system fields such as Id, State and AssignedTo would not be configurable. That was a mistake. Microsoft decided not to use the AssignedTo field used to determine who’s working on a task and opt to go with a field named OwnedBy. The vocabulary makes tons of sense but the change made it impossible to use Urban Turtle as it was with the new template.

When basic is not enough
This change was all that was required to build basic support for TFS Scrum with a new mapping file. We could easily define what fields should show up where, what states should appear in the task board columns, etc. We built this basic support within a single day, including refactoring the application code to support configuration for the AssignedTo field. However, we found such basic support to be somewhat lacking.

We started testing the application with the new template and we quickly realized that the state mappings pretty much made the task board impossible to use with Product Backlog Items and Bugs. These two types have the following states: New, Approved, Committed, Done and Removed. We ignored the latter and configured the first three to show up in both the To Do and In Progress columns and mapped the Done state to the Done column. However, the transitions configured between the three active states made us realize that only the Committed state actually made sense in the task board.

We thought that choosing to hide new and approved work items from the task board would cause confusion when users would look at their task board and search for missing items. That’s when we decided to implement two new features to facilitate the state transitions.

New Feature: Approval
Product Owners can now approve PBIs with a single click when looking at their backlog in the Planning Board. This feature can be configured as a state transition in the mapping file and could be used with other process templates. In the case of the TFS Scrum template, we’ve mapped the New -> Approved transitions for PBIs and Bugs to the Approval feature.

New Feature: Commitment
Approved work items still don’t show up in the task board. The task board is used to track work being done during a sprint. The team should never be working on something they haven’t committed to yet. It makes perfect sense with regards to Scrum. We could have implemented this feature the same way we did with the Approval, but while a Product Owner usually approves items one by one, a team commits to a set of PBIs. For that reason, we decided to make this a batch process. We therefore made it possible to commit to PBIs contained in a sprint with a single click, again from the Planning Board. This feature can be customized by defining the state transition that should be triggered when this feature is used.

New Feature: Sprint Details
The last thing we wanted to add to our initial support of  TFS Scrum was a way to manage the new Sprint work item type. This type was defined as a way to work around limitations in TFS regarding Iteration nodes metadata. It defines begin and end dates for the sprint, as well as sprint goal and retrospective details. We’ve made it easy to create and access this work item through the Sprint Details button in the planning board’s iteration list. This button only appears when the Sprint work item type is defined in the mapping, another customizable option.

Beta Release
It has been a mere two weeks since the release of  TFS Scrum 1.0 Beta (Visual Studio Scrum) and we are ready to give you a taste of the support we’ve built for it in Urban Turtle with the beta release of Urban Turtle 3.2. We hope that you will take the time to give it a try and we are looking forward to hearing from you  as we strive to improve the Turtle and accomplish our mission to enable your team to create kick-ass software – fast and sustainably.

All members of Team Urban Turtle are great fans of the Montreal Canadiens and we were quite sad to hear the news today that Halak had been traded to the Blues. While working on the past few releases, we fed on the adrenaline rush generated by Halak’s breathtaking performance during the playoffs. We’re disappointed to see him go but we wish him the best of luck with his new team.

There has been a debate in the Scrum and Kanban communities about having iterations  (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion.

I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.

My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.

When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.

Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.

Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.

I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.

A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.

Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.

While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.

I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.

Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.

This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:

1. How people perform correlates to how situations occur to them.
2. How a situation occurs arises in language.
3. Future-based language transforms how situation occurs to people.

I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.

In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.

Once again the team has committed to a new release Monday morning.

This is the plan for the next trip !

In the first sprint, we will make sure that the Turtle can sprint with the new Team Foundation Server Scrum v1.0 template announced at TechEd on Monday. You can download the new template here. We are really excited that Microsoft has decided to jump in the scrum world!

In the second sprint, we will implement a natural way to filter areas and iterations using a tag concept. You will have the option to put a push pin on some areas and iterations to apply a filter based on those selected and work with a subset of the work items. This will simplify backlog visualization and make sure the team’s focus is on delivering awesome software sprint after sprint.

This will help you doing enterprise scrum and complex project management with the Turtle.

If you want to manage your projects like one big project as suggested by Martin Hinshelwood on his blog, this feature will let you do that with Urban Turtle. I think you will really like this new feature.

Send us your comments on the forums!

Dominic !

We’re proud to announce that Urban Turtle version 3.1 is now available for download! Team Urban Turtle has been hard at work since the release of Urban Turtle 3.0 and the latest version is a true showcase of all the efforts we put in this product during every sprint.

Key highlights of Urban Turtle 3.1 include:

Support for Areas
Areas are now supported in Urban Turtle. Just like iterations, you can easily organize your backlog using areas with a simple drag and drop.

Ranking across multiple pages
We’ve designed a more convenient way to rank stories across multiple pages in the planning board. We’ve replaced the concept of pages with one of card stacks. While the stack itself cannot be moved and its number of stories is fixed, you can easily expand them with a single click and push a card onto the stack with a simple drag and drop. We feel this implementation is much more akin to how a product owner would manage a large set of user stories written onto index cards. We hope you feel the same way, but if you don’t, please do ensure that your voice gets heard in our forums!

List View Display Option
In the planning board, a new option allows you to select whether the area or the iteration should be displayed on the card.

Reduced installation footprint
We’ve always had the goal to minimize Urban Turtle’s impact on TFS installations. We were looking for the smoothest way to append our Planning Board and Task Board tabs to the TWA interface. The result in this new version is a single configuration change in TWA’s web.config file.

Quick access to reports
We’ve added a shortcut on the toolbar to have direct access to project reports from the planning and task boards. We have plans to go much further by providing access to real-time reports right inside the planning or task board tabs. We are convinced that your feedback and incremental steps will guide us in the right direction!

We love to hear from you and we love even more to validate that we deliver software that truly fits the needs of our users.

We recommend everyone already using Urban Turtle 3.0 to upgrade to this new version. For others who have not yet taken the red pill to transport their team to a world where they are enabled to create user-delighted software fast and sustainably, please give it a try by requesting your free 30-day trial.