Velocity and Capacity are two terms commonly used for determining how much work a team can perform in a given amount of time. Agile development is customer-focused development, and as such it is important to know for small periods of time how much a team can achieve.
Determining Velocity
A teams velocity is an estimate of how much work it usually completes in a given time period. The figure is based on how much work a team has completed recently. Velocity is usually measured in either hours of points. Agile teams determine how they will be measuring the time and difficulty of tasks, whether they use a point system or a number of hours is up to them.
Determining Capacity
A teams capacity is an estimate of how much work it can complete in a given time period. The figure is based on the ideal amount of time available within the team. This number is created by adding together the sum total of ideal hours each developer has for the project in the given time period. If there are two developers each working 24 hours/week then the weekly capacity is 48 hours. If you’re using points and not hours you can convert that into points.
In Iterations
An iteration is a period of time where an agile team is going to move through every stage of the development process all the way from planning to deploying an update. Agile teams tend to do one or two week long iterations. Velocity and capacity are used to help teams commit to a certain amount of work to be accomplished during an iteration. Since the team knows how much they’ve completed previously and their potential capacity for work, they are able to determine if the workload they’re agreeing to is reasonable.
Author’s Note: It is important to customize agile development based or your team and the needs of your team. The content here is a suggestion based on what has worked well for in the past.
Silverlight is a great technology, and one thing that really makes it a treat to work with is the ease with which one can access the code inside the XAP file. Yes, this means that someone can look at your code, SO DON’T PUT ANYTHING SECURE IN THERE! I took Jeff Blankenburg’s Click the Button contest.
So for a while I though Jeff had tricked me on that puzzle until I opened up the XAP file and looked at the source code. On the last page of the Silverlight you see this screen.
So what’s the big deal? Well, the level before it was titled “Level 10”, so I figured Jeff was trying to pull a fast one and there was more to this seemingly innocent page. So I tried to find how to get beyond this level 12 to the real one. I eventually took the smart route, and I opened .NET Reflector and pointed it at the DLL file for the contest.
How did I do that you ask? Here are some quick steps for looking at the source code of a Silverlight application.
Step 1: Download the .xap file. View the source of the HTML page or look at the NET tab in FireBug to get the .xap file and download it.
Step 2: Rename the file to .zip and open it. Yes, a .xap is really a .zip neat huh?
Step 3: Unzip the file and find the dll you’re looking for. In my case it is called “ClickTheButton.dll”
Step 4: Open up .NET Reflector and open up that dll file.
Step 5: After examining the dll you’ll be able to see all of the code. In this case I can see that Jeff actually has 13 levels he created for this application.
You now have a choice to make. You can ask Jeff Blankenburg what happened to the other puzzles or just go and take a look at the code and see which levels are missing.
Last night we had a great HudsonSC meeting. People started showing up around 5:30, and I had the opportunity to meet and talk with a few new attendees during that time.
Lightning Talks
At around 6:00 we got things started. Kevin Kuebler started us off with an interesting talk on BDD where he showed some interesting code using MSpec. As usual, he was unable to keep his talk under 10 minutes. We will not fault him for that though, since he discussed the topic well and showed some cool code.
Following Kevin’s talk, we had a well-timed talked from Yasir Drabu about the Unit of Work pattern, which I in no way pressured him into giving at the last minute. Yasir let us know that he was currently implementing this, and he would show us the eventual implementation at a later meeting.
Open Spaces
Our open space discussions start at the same time pizza arrives, so people can sit around eating pizza and discussing interesting topics. The selected topics of the evening were “How to promote agile practices at your workplace” and “Automated build processes”.
I’ll defer to someone else about how the agile practices open space went, but I do believe the build processes discussion was interesting. Continuous integration, build automation scripts, and database change management were the hot topics of discussion among that group.
Coding Exercises
As usual we finished up the meeting with some time spent pair programming through some coding exercises. This time we took our second group attempt through our customized version of KataPotter.
We had a few interesting solutions to the exercise, and each one handled the optimization for getting the price down differently. They all seem to work effectively according to the unit tests. I know my solution was very different from the previous one I used to solve this exercise.
In Northeast Ohio? Come to HudsonSC the third Wednesday of each month in Hudson, Ohio.
As a late adopter of CodeMash I can say that version 2.0.1.0 was a great event. There were hundreds of developers there ready to learn and try new things. The intelligent, interesting people sparked many worthwhile conversations. If you’re in the area around Sandusky, Ohio, I highly recommend that you attend the next CodeMash.
Not Your Everyday Conference
I was very pleased with how things were handled with CodeMash. It didn’t feel like the standard “sit in your seat while someone talks at you for an hour”. I really think that involving people is the best way to spread knowledge. One of my favorite quotes touches on this perfectly.
Tell me and I forget. Teach me and I remember. Involve me and I learn.
I can’t say what it was like at every session at CodeMash, but the sessions I attended tried to include the audience when possible.
Software Craftsmanship Workshop
CodeMash has a precompiler the day before the event. The precompiler is a day with two time slots of four hours each. Steve Smith and I ran a workshop during that timeslot. Our Software Craftsmanship workshop went very well. We started by introducing everyone to the concept of Software Craftsmanship. At the end of the day I like to boil this down to people caring about writing good, clean software.
So how does one get better at writing good, clean software? Practice.
- Write something small and write it well.
- Try new approaches to a known problem to see if you can improve upon it.
- Follow along with a known good solution and understand how someone else solves things.
- Take some bad code and refactor it again and again.
In case you haven’t guessed the goal of our workshop was to give people some practice as well as show them how they can practice on their own in the future.
We started with the Bowling Game Kata from Uncle Bob Martin. First we went through the slides discussing at each step what he was doing and why he was doing it. This is a great exercise because it lets you see what Uncle Bob does when he hits a wall and needs to back up. At one point in the Kata he realizes that the path he is going down is not correct. This shows you how to identify this situation and then how to resolve it.
After this quick introduction we had everyone dive in with their favorite language attempting to calculate the score of a bowling game.
We continued on with some other exercises including: discussion of followed by implementation of a Supermarket Pricing system and we ended with a bit of fun with FizzBuzz.
I hope those who attended enjoyed the experience, and I welcome everyone to come by our Hudson Software Craftsmanship meetings which meet on the third Wednesday of the month in Hudson , Ohio.
Coding Dojo
This year CodeMash also had a Coding Dojo dedicated to these exercises. Instructions were provided explaining the requirements of the exercises. Some are katas like the bowling game and others exercises to challenge you with creating a good, clean solution to a relatively simple problem.
We recommended people work in pairs with someone they didn’t know, but we had a few people working solo.
Sara Ford stopped by the coding dojo and it seems had a beef with my overuse of the word “kata”. If you’re interested, Steve Smith wrote an interesting response discussing coding katas. The bowling game is a kata to be followed along with and matched exactly. The more closely and exactly that one can match how UncleBob does the kata the better. Some of the other challenges presented there I probably should have titled as “exercises”. Next year, I’ll make sure to have more time to prepare the coding dojo. I hope to see you there.
I will be attending a great regional event this week. The event is called CodeMash and it is located in Sandusky, Ohio. As the CodeMash site describes it.
CodeMash is a unique event that will educate developers on current practices, methodologies, and technology trends in a variety of platforms and development languages such as Java, .Net, Ruby, Python and PHP.
I hope everyone attending has a safe trip there and has a good time. I look forward to seeing you there. You’ll find me at the Precompiler Software Craftsmanship workshop as well as at the Coding Dojo, which will be open Thursday and Friday in the Banyan room.
I look forward to seeing you all there. If you don’t make it out this year, there is always next year. Have a great week everyone!
