Saturday, December 27, 2008
Tuesday, December 09, 2008
First I change few of the labels for the standard fields from the Conchango template:
Business Priority is changed to Business Value since the word "priority" has a certain connotation of order. I also implement a SuggestedValues rule with values ranging from 100 to 1000 with increments of 100 (100, 200, 300, etc.).
Estimated Effort (days/story points) is changed to just Story Points since I really encourage teams to not use days or hours when estimating the Product Backlog. I add a SuggestedValues rule to this field with the Agile standard of the Finbonacci sequence variation (1,2,3,5,8,12,20,40,100). Some clients use the planning poker cards from Crisp, but I do not include 0, 1/2, ?, or the Coffee Break card.
I also change the description on the Conditions of Acceptance section to include "or How To Demo Steps" since I really like using this technique over just a bulleted list of acceptance criteria.
I also add two new fields:
Return On Investment which is a read only field calculated by dividing the Business Value by the Story Points. We use this as additional perspective when ordering the Product Backlog. The value is updated by a web service created using Howard van Rooijen's project template for TFS event subscription end points.
Product Backlog Type which is used many different ways depending on your Agile tool or general philosophy. My version has three allowed values:
- User Story which is exactly what it sounds like. All these entries must fit the user story format.
- Technical Requirement which is for any behind the scenes work like refactoring, building supporting components with no UI, etc. This helps identify which items require functional tests to be created (meaning a User Story) or those that just need to be regression tested with the current suite of tests.
- Epic which is used for placeholder entries. Some people like to use TFS Areas for this but I prefer to put it at the Product Backlog level. It allows stakeholders to throw pie in the sky ideas on the backlog. Our rules specify that an Epic is not estimated, is always last in delivery order, and can never be added to a Sprint until it is broken up into acceptable User Stories with a Story Point value that can be done in half a Sprint.
I also add some new work flow steps:
Ready For Test is something the Conchango template puts at the Sprint Backlog level and I prefer to have this measured at the Product Backlog level. There is some contention on this even on the Conchango forums. My thought is that a task like "Create class to hold search criteria." cannot be tested but its corresponding User Story ("Search Online Catalog") can be.
Failed Test and Passed Test are two optional steps I sometimes put in to follow Ready For Test. This depends on how integrated the testers are with the development team. If they are very integrated and the team is good with simply communicating failed and passed tests verbally or via email then these can be left off. I have had less integrated QA teams that were also not co-located with the team and we found these steps necessary to keep up with test results.
And finally I organize the form a bit to keep it symmetrical and grouped a bit more clearly.
These changes are not necessarily a good fit for every team and I really try to understand the level at which each client can adopt the Scrum processes before we run head first into customization. I have found these changes to bring value to the process for the majority of time.
Monday, December 08, 2008
Here is my Quick Launch bar in all its shortcut glory:
That's it. Soak it all in. Bask in its gleaming aura of one click access goodness.
You got your Open Destop, Internet Explorer, FireFox, Outlook, Shortcut to my work web mail (no POP3 access you big jerks), and OneNote (ah...OneNote).
So I do not put a lot of links on my Quick Launch. And I do not put that many on my Desktop either. Why you ask?
Is it because of my Zen like knowledge of shortcut keys? No. I don't even think my ALT button is working.
Is it because of some Toolbar and Desktop Feng Shui philosophy? No. I tried that and the incense just gunked up my keyboard (Maybe that is why the ALT button is broken).
Is it because I simply do not actually do that much work? Maybe. Some co-workers might think that. :)
Mainly it is because I do not have that much installed on my local hard drive. I normally use VPC images that actually contain the bulk of the applications and tools I use. And for what I do have installed locally, I just keep the shortcuts off the Desktop and Quick Launch because I like a clean interface. I do not mind a few clicks to find things in my Start menu. My Start menu is organized in a very set pattern that I have used ever since there was a Start menu and I have just gotten used to it.
Sunday, December 07, 2008
With 4 children at home (all girls 11 yrs. To 6 months) and a 17 year old son, I don't seem to get as much free time to be active in the local development community like I used to. After working all day, dinner with the family, and the logistics of homework/housework/etc., when I do finally sit down in front of the computer (usually around 11:30 PM) it is very tempting to turn it off and just go to bed. But when I hesitate to sit down and write a blog post, investigate a new technology, or participate in a local community event, the people listed below are the ones I think about to inspire me to stay involved. This list below reflects people I interact with regularly either in person or online that serve as an example for involvement in the developer community. I think it only right that I pay them a little homage:
Brian Prince - Brian is the Microsoft Architect Evangelist for my region and is always willing to help out with our local community events. He is also very helpful to me personally whenever I ping him for assistance. I have seen him take personal interest in more junior members of our local community and encourage them to become involved when sometimes these people are left out.
Elijah manor - Elijah a prolific blogger and tweeter. I know he is very involved in his family and church and where he finds the time to do this I have no idea. Almost every day I follow a link from one of his tweets and discover something knew.
Michael Neel - Mike is the .NET User Group leader in Knoxville and I have worked with him at several local and regional events. He is very passionate about the community and it seems he is always driving somewhere (usually a great distance and on his own dime) to participate in community events. He is the one who got me started on filling up my iPod with developer podcasts to listen to while I am in the car (that's an hour of knowledge every day).
Evan Hoff - Evan is always traveling to go to a developer conference or referring a new technology book to me. He seems to know just about everyone in the Agile/ALT.NET community. I guess it helps that he is single and has the time to be so deeply involved but I remember when I was younger and single I did not have the dedication for that level or effort.
Corey Haines - I met Corey at devLink 2008 and found his outlook very refreshing. He is very passionate about being the best developer he can be in any language. He recent endeavor to travel the region pair programming with people all over to learn more is something I would never have the guts to do.
There are more people and I apologize to those I did not mention.
Saturday, December 06, 2008
When you open the Sprint Task Board you are prompted to choose a project then choose a Sprint. The Sprint you choose is actually an item in the hierarchical list of Iterations. I have always just selected my specific Sprint, but if you choose a Release you will then see all of the Product Backlog items under that release. So if you have previously performed your Release Planning and assigned Product Backlog items to their projected releases then they should show up. The image below is a view of a sample Product Backlog viewed in Excel. Notice that all but one item is assigned to the Release 1 Iteration.
When you open the Task Board application and choose Release 1 for this project you will see all of the items that were associated to Release 1 (or a Sprint in that Release). Anything not assigned to that Release will not be shown.
Most of the time we have used Excel during Sprint Planning meetings since we tend to be adding quite a lot of items and using the query view in Team Explorer was tedious. Using the Task Board app is less tedious than Team Explorer but still not as easy as Excel. So you can still use Excel to rapidly enter Sprint Backlog items and then publish them back to TFS, but since you cannot link items in Excel they will not be connected to any Product Backlog items. You can then open the Task Board app and open the Orphaned Work Item section to drag and drop these Sprint Backlog items to their corresponding Product Backlog item.
So while this option does not provide a good option for Release Planning, it is one possible solution for Sprint Planning. Using the Task Board app can give the team a more tactile feeling during the process. Seeing item represented on the screen gives you more of an idea for the scope of a Sprint/Release.
I still like the interface provided by VersionOne for Release Planning. Not only does it provide an easy to use drag and drop interface, it provides feedback on capacity as you go (see a demo here).
So thanks again to Jeff for prompting me to take another look at the functionality in the Conchango Task Board application. Now if they could just rip off the features in VersionOne I could get down to only two applications!
Monday, December 01, 2008
- Iteration Planning/Backlog Maintenance (-1): This is probably my most disappointing set of features. I never found the work item queries view in Team Explorer or Excel a decent interface for organizing the Product Backlog and Release/Sprint Planning. Products like RallyDev and VersionOne (which both have connectors to TFS) had easy to use, drag and drop user interfaces that made these features more tactile. Stephanie Saad shows the new Agile planning templates in this Channel 9 video. All that was really added were some Excel sections for capacity and release number crunching that we had implemented ourselves in Excel about a year ago. Microsoft may be simply relying on ISVs like Rally and VersionOne to fill in this space but I hate to buy another product (on top of VSTS/TFS's substantial cost) to get this functionality.
- Unit Testing/TDD Support (+1): While I am not a TDD zealot I do believe in test early and test often when it comes to unit testing. For those who really wanted to write their tests first in true TDD fashion it was a little kludgy to get a unit test class written without any of the references of target classes already defined. There are some new options while creating your unit tests to automatically create your target classes and namespaces as you go. Karen Lui demonstrates this in this Channel 9 video. These features are definitely going to make writing unit tests first easier.
- QA/Functional Testing (+1): This functionality I have not gotten to play around with as much so I have really only gotten an idea of how it works from this video. The new testing application, Camano, is a stand alone application that QA/functional testers can use to execute manual test and record them for automation afterwards. There are also the other cool features for recording video while testing and saving metadata about the path the tester took to get to the bug. All this info can be bundled up in a bug report that can be sent and tracked through TFS.
- Self Documenting Code (+1): Since there is less concentration on documenting architecture and design information up front in most Agile processes, techniques for making your code/application self documenting are highly recommended. But even these practices never gave you those great UML diagrams that really showed the "big picture" of how the solution as a whole was built. But now with some of the "bottom up" design features (demonstrated here), you can generate not only the standard class diagrams, but sequence diagrams also. The Architecture Explorer is also a very cool way to browse the basic structure of any .NET solution.
- Code Quality [Adherence to Architecture/Design] (+1): Enforcing code quality in a self managing Agile team is sometimes a difficult task. Pair programming and good code reviews are good ways to ensure the developers are following the basic architecture/design of the solution. The Layer Diagram (same video as above at the 30 minute mark) is a great way to layout the basic boundaries of your application that can actually enforce that the underlying code does not cross boundaries.
So far the Release/Sprint Planning and Backlog management is the only area I found wanting. Otherwise I am very eager to start using 2010!