Using Areas & Iterations in SEP TeamWorks

TFS supports a concept that allows you to organize your work items into different functional areas and chronological iterations, called Areas & Iterations. This post shows you how you can use these features to groom your Work Items using SEP TeamWorks.

Areas & Iterations in TFS

Areas & Iterations can be accessed from the Team Explorer.

Visual Studio 2012

Selecting this item opens a single dialog that allows you to configure both Areas & Iterations. Note that you’ll need to be an administrator for your Team Project in order to make changes.

Areas

The following shows an example of functional areas for a product.

Iterations

The following shows an example of Iterations.

Both Areas & Iterations can be nested so you can structure them any way you want. The system is also flexible if you delete an item you’ll be prompted to select a new value work items that would be impact.

Querying Work Items based on Path

When you query Work Items, you can find all items within the hierarchy.

Using Swim Lanes with SEP TeamWorks

SEP TeamWorks doesn’t have any built in mechanism to filter your TFS queries, but it has a fantastic feature that let’s you group content using swim lines.

Swim Lanes can be turned on any query (except hierarchical queries), simply right-click (long-press on your touch device) to open the context-menu and choose Edit Swim Lanes. You can also access the swim lanes from the Options button in the UI.

You can create Swim Lanes for most fields, assuming that the Work Items in the Query support the fields you’re grouping by:

Here’s the same query with a swim lane enabled for Iteration Path.

Where swim lanes really shine is you can use them to edit your work items without opening them simply by dragging them into another lane.  Here’s some great examples:

• Bug Triage: write a query that pulls back all new bugs then use swim lanes for Severity, Priority, Found In or Triage status. 
• Product Planning: write a query for all User Stories then use swim lanes for Area path, Iteration path, Risk, Story Points
• Grooming the backlog: write a query for all Tasks then use swim lanes for Activity, Area, Assigned To, Remaining Effort

As you can see, with a little bit of planning and some creativity you can customize the tool to fit your needs. In the upcoming posts, I’ll look at common queries and exporting information out of TFS into other formats.

Until then, Happy Coding.

Using User Stories with SEP TeamWorks

When I first started with Kanban over a year ago, the post-it notes on my whiteboard represented Tasks and Bugs, which for the most part worked great. The two main challenges raised by the team, were:

• Developers had a hard time visualizing related tasks, which made it difficult to organize and plan effort. We also had the risk of being unable to deploy because some related tasks were unfinished.
• Project Managers had a hard time reporting progress on high-level features. Although they had access to the Kanban board, organizing a status report from low-level tasks and bugs wasn’t sufficient.

Kanban is intended to be an adaptive process, meaning that it’s not a full-featured methodology and you pretty much have to add your own rules and concepts to it so that you can adapt it to your needs. Other methodologies, like Scrum, have solved my problem by using User Stories to represent high-level features that you can group related tasks under. Developers could see related tasks; project managers could report progress on Stories – win / win. The only remaining challenge was how to represent User Stories on a whiteboard? (How do you associate post-it notes with a Story? Do Stories move on the board like Tasks do? If a few of the tasks for a Story are “ready for test” does the status of the Story change?)

I struggled with this challenge until I switched over to a digital Kanban board which afforded us the ability to produce different queries over the same data. We’re using TFS 2010 as a repository and SEP TeamWorks as a front-end to visualize task effort.

Querying and Displaying User Stories

The Agile Process Template used by TFS 2010 includes a User Story work item type which you can link tasks to in a Parent-Child relationship. You can write a simple query to obtain all parent-children tasks. 

Note that the TFS query that I’m using is a Work Items with Direct Links query, which allows me to pull back Children tasks as well as Related bugs. I also don’t nest my User Stories – this technically works within TeamWorks, but it seems a little odd and needs some further investigation.

SEP TeamWorks supports hierarchical tasks out of the box. Stories and their children are represented as swim lanes, with the first column representing the Story.  Note that because Stories are broken into swim lanes, you can’t use TeamWork’s swim lane feature to further refine the query. If this is something you want, you’ll have to set up different TFS queries.

Adjusting Kanban Workflows

While the workflow that I’m using for Tasks and Bugs would work for User Stories, it seems a little heavy to duplicate the process for Stories. I simplified the flow to make it easier to manage and for reporting status.

The flow for my Tasks and Bugs, which I’ve outlined in my previous posts, is:

• Proposed
• Active
• Selected
• In Development
• Ready for Test
• Testing
• Acceptance
• Closed.

For my User Stories, I’ve simplified it to:

• Proposed: the story does not have all the details, yet.
• Active: the story is well defined and is actionable.
• In Development: the story is being developed or validated by developers
• Testing: development has completed and the testers are running their test cases
• Acceptance: test cases are complete and its ready for client review
• Closed: the feature has been accepted / shipped / etc.

Note that SEP TeamWorks uses the Status column from all Work Items into its UI so I’ve repurposed my existing status definitions to simplify things.

Daily Operations

As mentioned previously, having our Kanban board as software solution allows us to query and represent the data in different ways. I use a combination of three different queries for my daily operations:

• Product Planning: I query only User Stories which allows me to see the high-level status of the project at a glance. I heavily use Areas & Iterations (I’ll blog about this next) to help organize and plan the project.
• Iteration Backlog: I use a hierarchical query as shown above to represent the current iteration.  This query allows me to see the detailed status of the Story
• All Work Items: This query returns all Tasks and Bugs and it resembles the Kanban board I’ve fallen in love with. This query allows me to see bottlenecks, developer allocations, etc.

Conclusion

Having User Stories has made a big difference for how we track and organize our effort, but it’s not without its challenges. There’s a special knack to writing stories and it takes some practices to get used to the format, which I’ll have to blog about later. For now, I hope that this post shows you how easily it is to introduce Stories into your Kanban flow.

Until next time, happy coding.

New updates for SEP TeamWorks

For the last 8 months, I’ve been using SEP TeamWorks as a front-end for my all digital, TFS-backed Kanban board. The experiment has been relatively successful, and I’m constantly revamping my model to make it fit for our style of projects. The real success of using Kanban with this tool has to be its adoption to other projects within the organization. While my hand-waving evangelism has played a part, this expansion is largely due to the position of my desk: I’ve been sitting directly between the Project Management group and the developers and see a fair amount of foot traffic every day. Every developer, project manager, designer and executive has walked by my multiple-monitor, touch screen environment and eventually, like bees to honey, they ask, “what the hell is that??”

While I’m very pleased to see Kanban adoption within our organization, I’m also very glad to see that SEP is using an iterative release cycle for their TeamWorks product. Late last year they added an auto-update feature and now surprise updates makes it feel like it’s Christmas all year long.

Here are two of my favorite new features from the latest release:

Revamped “Add new” menu

There are two ways you can add new work items inside TeamWorks.  The first way is through a main menu at the top of the screen; the second is a context-menu that you can bring up on an existing work item. This context-menu option has been completely reworked.

The new version opens a dialog window that let’s you specify the WorkItem Type (Bug, Task, etc) and relationship (Parent, Child, Related, etc) to the current item.

This dialog is very similar to how it appears within Visual Studio, which means I can do more from the touch screen. The other clear advantage to using the context-menu is that the newly created work item inherits the iteration and area of the linked item.

Card Editor

This release has a brand new feature that allows you to edit the appearance of your Kanban cards. This is a very simple but very welcome addition to the tool.  The tool allows you to customize the fields and layout for each type of card, and you’re able to reuse your layouts from other queries or projects.

Here’s an example of a Task that I’ve customized by placing the Remaining Work field in the bottom right hand-corner, horizontally right-aligned.

Here’s a few customizations that I’ve used on my most recent project:

• User Stories: add the Story points to the bottom of the card
• Tasks: Original Estimate, Completed Work, Remaining Work
• Bugs: Priority and Severity

Well, that’s all for now. I’ve got Inglorious Basterds queued up on my DVR and a nice cool drink waiting for me.

Happy Coding.

Turtles all the way down

A while back I had a heated passionate debate about dependency injection with a colleague. He was concerned about the lifetime of objects and which object had the responsibility of creating the other. While some of his points were valid, I took a position that a lot of that doesn’t matter if you allow the Inversion of Control container to manage this for you – simply push dependencies through the constructor. The argument, comically, sounded a bit like this:

Colleague: “But who creates these dependencies?”

Me: “That doesn’t matter. Put them in the constructor, let the container take care of that.”

Colleague: “Ok, so who creates this object?”

Me: “Again, doesn’t matter. It’s placed in the constructor of it’s parent, along with any other dependencies it needs.”

Colleague: “Arrrg! Who creates that object??”

Me: “Dude! It’s turtles all the way down.”

The reference “turtles all the way down” is to what I believed to be an Iroquois cosmological myth that the earth is flat and rests on the back of a great tortoise, which in turn rests on top of a larger tortoise that is on top of a larger tortoise, etc, etc… all the way down. I recently discovered that source of this expression is unknown and there are many different variants of this theme. The best variant is the Hindu belief that the earth sits on top of a tiger or elephant, which is on top of a tortoise, which is then, well, …uh, suppose we change the subject?

Over the years, I’ve adopted this expression to represent a fundamental lesson I was taught in object oriented programming: “objects should not have a top”. That is, objects should be open ended, allowing them to be extensible or mixed-in to other different applications and implementations. Our objects should be aware of their dependencies but not in control of their implementation or lifetime, and the framework that glues them together should be abstracted away. This idea is echoed by the Open/Closed principle and the Dependency Inversion principle, and it is demonstrated every time we write automated tests – the first consumers of our designs.

In my analogy, turtles all the way down accurately describes how I feel we should design our objects, but to my colleagues credit it doesn’t reflect that at some point there must be a reckoning point – someone must know how to assemble the parts to make a whole. I suppose Aristotle would point to an unmoved mover, responsible for the order of the universe. Douglas Adams would point to the man behind the man that probably has another man behind him. I’d point to some top-level application service that has the configuration that magically wires everything together.

It feels good to know there’s some sort of finality to the infinite regress problem: our application glues it all together.  So maybe now we can catch up on our sleep, knowing that we don’t have to realize infinity before we can close our eyes. At least until we see our application as part of a batch process in a much larger service, hosted in the cloud, resting on the back of a very large turtle.

Happy coding.