Valuing your assets

Reading From Good To Great is probably an eye-opener for all that believe that there is potential in their organisation but that there is something lacking. When we started this project, this was the book I was reading and it's a book which still inspires me.

The first advice, having the right people on board, is the most difficult. For many reasons. But it's crucial. I recommend the book to everyone who wants to do something amazing in their professional life. But if you do not have the time to read the whole book. take the time reading this short article on valuing your people. How much does it cost your company having the wrong people on board?

PDC Badges - scrapbooking for developers?

Reading about the PDC badges, I can't help thinking that the citation "Collecting Badges is the way for Attendees to capture their experience at the PDC conference" is something I thought I would find when traveling to Disney World with my four-year-old, not the Microsoft Partner conference.

But then I realized that this is scrapbooking, for developers. And I never understood that either.

What do you test?

The latest releases have been quite hectic, and I've not had time participating in the acceptance testing but the release for tomorrow was up for some manual cranking by the mrs Product Owner today.

I don't know if I'm a good tester. I believe I'm not. But I always get our applications to crash. It's amazing. Give me five minutes and I have a crash. This time the errors were not in this product increment but has hanged on for a couple of sprints. Non of the users has complained either. So, how come? There is one simple solution to the question - I know where the possible loop holes are. I know my developers so I know what they overlook. So, I know what to test. This is one of my strengths (I think) as a product owner. Knowing the guys and knowing the application.

But it makes me a lousy tester. A good tester prevents these bugs from making it into the product in the first place. If I was a good tester I would do something to make this not happen again. Because if I know where to look, how come I don't share this information on the sprint planning meeting?

Mainly because I then participate with the product owner hat on my head and even if I'm dedicated to quality, I'm simply not wearing the tester's hat. Interesting. I have to do something about this but I'm not quite sure what and how.

What I also find is that I discover those small annoying bugs, usability wise, which makes the application unpredictable. And the funny thing is that when I ask the users if they don't find X annoying, they do, But they just take it for granted. That is sad. We develop for the users and they are so used to systems being a pain in the ass.

This is not because we have a lousy product. I think our product is wonderful. But more that users are so used to systems not being predictable and that they have to have this strange routines to go around the obsticles. The worst example was a lady whos computer had so low memory she had to turn of her screen to be able to complete a print out. And she never complained.

Well, it's pushing Friday and that is release day. Hurrey.

Something I haven't done in a really long time...

Today having to pick up the car from service on a site about 20k from our house, I decided to take the bike. I haven't actually taken the bike where I was going and I haven't taken my bike so far before.

My bike is a Brompton foldable bike and when I was a biking girl last, I used a better hybrid with twenty something gears. But being myself and I, I didn't realise that this could cause a problem before I left my son at daycare and mentioned where I was going (having a foldable bike is one of the best ways to start a conversation) and the woman at daycare started asking if I could really take the bike that far and she wondered which way I was going to ride.

Well, I guessed it wouldn't be a problem. And of course there was non. Well, of course I had to turn back once or twice when I couldn't take the bike on the highway or when the signs didn't show the proper path. But riding 20k in september sun on a 3 gear bike shouldn't cause a problem for a healthy gal under 40. And it was kind of fun going places so near from where I live and being almost a bit lost. Not knowing if you would have to turn back. And the disappointment when the ride was over in just over one hour. I was just getting started but now I was out of excuses for being out in the sun.

Using Area in TFS work item templates

Migrating to Conchango scrum template, I've lost the fields for epic and themes on my product backlog. You can guess how much I long for Rosario's hierarchal structure for work items. This would truly solve my problems with epics, themes and small stories.

The problem is adding fields to the template makes upgrades a hardship. So we do not want that. Concatinating the epic/theme into for example the description field is not a good option: I use epics and themes for making pivot tables in Excel and that would just not make it worth it. The reason for me using pivot tables in Excel is that I can make all kinds of analysis of for example cost per epic or theme (to calculate if the functionality was worth the price).

It is also a good thing to calculate the ration of bugs on different themes or epics to know which areas are prone to be infested. Which should make us aware of which areas should be better automatically tested when changing the stuff again.

But back to the problem with epics and themes. As from Monday, I store this in the Area field on both bugs and product backlog items. On the highest level I keep the themes and under each theme I've defined a number of epics. Since the field is hierarchal, I haven't written the epics as true epics as described by Mike Cohn but rather a few words (for example theme resource planning with the epics choose the right resource and handle sick leave.
This is not optmal, since an epic can belong to many themes, but the cost for another solution is frankly too big.

New tactic during sprint planning meeting

This Monday we held a sprint planning session and I introduced an element from my days as a computer trainer. As always, I started by giving the objectives of the sprint. This time I printed this down in big letters on a paper.

Then, during the session whenever giving a statement I finished this with the questions: "do you know why?" and the developers could themselves present an answer. By doing so, they become more involved in the objectives and mis understandings were discussed up front.

I used this technique, common to many theories for education, all the time when I worked as a computer trainer. Why I dropped this when educating our developers on the problem domain is my failing to see the pattern.

The product backlog's back side

When you participate in scrum training sessions or when you read about scrum in all those books people like to sell, the product backlog is described as a list of stuff that need to be done. Well, that's the front page of the product backlog. And one of the needs.

But you also have the backside of the product backlog - what you have accomplished. I've sometimes seen these fancy project burn downs or product burn downs and they are a part of this question: what we have done. But the question is larger than that, especially for a project where muliple versions of a software is being used.

I'm talking release notes, delivery notes and information in the line of questions as "when did we change that stuff?" and "since I'm doing some acceptance testing, what should I be testing"?

When I came back from this summer, I found that the backside of my product backlog haden't been given any love. Everyone was focusing on getting stuff done that they didn't take really good care to documenting what had been done and it's taken me almost a month getting things sorted out - which bugs had been fixed, outdated and changed behaviour?

When you form your product backlog, think about your needs for history: do you want to dig into some code to know when a feature was implemented or a behaviour changed? I'm pretty bad at reading code so I'm happy for my delivery notes. And so is our customer operations. Find your objectives for the backside of your product backlog and do so before the questions start popping up. Fixing the backside is a small task if you do it regulary, but fixing it afterwards is boring, a hazzle and takes a lot of time.

Self organizing teams?

I believe much in personal freedom and responsibilty. From kids to old people, I think it's best if everyone can do stuff the way they want them done. Then there are of course rules which states if the ways are legal or appropriated. But the concept of being responsible for how you carry out a task should be very much up to you. I think most people work better then.

So, this is self organizing teams in for example Scrum: you get an objective and you are free to meet that objective they way you feel fit, following the standards for how things in general are done. So, if the guidelines states TDD, you can carry out the tasks any way you want, given you work test driven. Just an example.

What I've found, though, is that some believe that self organizing means setting your own objectives. I've heard management people complaining that self organizing stuff means the guys just do what they want and I've heard developers complain about objectives given because they are self organizing.

So, just as in the American legal system which separates setting the rules from implementation, this must be clear to everyone:

1. The company sets the standard - which are the basic rules for how things in general are done. Going lean and using TDD is a strategic decision and it's not up to the developer or a single user to decide if that is good or not. And like with legaslation, some rules are set by the highest authority (state<-->company leaders) and some rules are set in the municipal (city<-->team), because some rules needs to be applied on the organization as whole and some rules just applies to a small unit.
   
2. The product owner sets the current objectives for the coming sprint. And this should be read as "Do this, and I don't care how you do it" and the product owner shouldn't have to add "as long as you follow the guidelines/laws/rules".
   
3. The developers should work to carry out the objectives given by the product owner. As long as the objectives set by the product owner are met and the guidelines are followed they can work lying on the floor for all I care.
   

I see this as a contract between these three groups and once the contract has been breached, hell can break loose. The developer's don't like the objectives given by the PO, so they start developing what they think is best. The product owner think he/she knows how things should be made so he/she start pestering folks. And management start changing the objectives. The scrum horror show.

And let the games begin

I know my son likes to compete. I know my son loves to win. I don't know if "it's in his blood" or something we and his environment has pushed him into. But this is a string in him. How do I feel about that? Well, I like that he isn't the kind of person who just gives in. I don't like when he cries because he doesn't win. So, this is something we work with often. And during the summer and early autumn things have improved.

So, today I was happy when little Pete went to the playground and found a new kid to play with. I've never liked ball games and I'm the individualistic athlete so I'm happy that Peter likes soccer. And I was even more pleased to see him with this little boy just kicking the ball between them. Taking their time kicking the ball. Proud mama.

But then the other boy's father turned to the guys, wanted them to play in different teams, having their own goal. He volunteered as referee. Peter looked dumb stricken. The other boy grabbed the ball and tried hiding it from Peter. I was then stunned when the other boy threw himself to the ground, playing hit. The father played along and acted medic.

They are four years old. They are boys. Why? I felt that the father spoiled their fun today. I guess the father want a soccer player for a son and I see no error in wanting that. But one should always put the child's interest first and removing the play from the four-year-old is not in the child's interest. They are good at competing. The cooperation is a harder nut to crack. If you want your child to participate in a team.

Here be dragons

Being a skeptical girl, I've of course seen the movie "Here Be Dragons" by Brian Dunning. But I've also found that the term has some uses in agile estimating and planning poker.

If you haven't seen the film or if you're not into old maps (hm, I meet both requirements): When the old map makers were drawing their maps they did not have the complete picture. Where their peers had been they had some information (though not always true and often enough distorted) but there were those white spots where they knew there was "something" but they did not know what. And there many of the map makers draw the text "Here be dragons", and draw some evil looking creatures on the spots. Hey, no one has been there so there are probably some nasty beasts there.

It is not uncommon during estimation that I feel like those old map makers from the distant past and the developers discuss some features in (very very often) some legacy code, which we want to update or change. So, I put a mental note on those stories: here be dragons!

What that mean is that the estimate is not made by knowing but lack of knowing. We are moving into potentially dangerous surroundings and you never know what will happen.

But are ther dragons there? Well, in the story of the map makers things were not as terrible as they hoped or feared. But in the world of software development, there are more often than not some nasty dragon figures in legacy code.

Creating myths - you never knew how easy this is

I read today a wonderful story at the truly brilliant site Faktoider (a site dedicated to those stories everyone or many just take for granted, but seldom are true). The story is in Swedish, but since it's so nice, I've taken the liberty to translate it to English. For you fluent in Swedish, I recommend you read the original text. Text within [ ] are my clarifications to non Swedish readers.

The murders at Hökeberg
The following thriller from the [second world] war could until last week be read on [the Swedish] Wikipedia, until last week.

Hökebergs slott is a larger villa outside Kvänum in Vara kommun. The house has two floors, built in 1923 and says has been drawn by Ivar Tengbom, though the latter information has not been verified. Also, the origin of the name is unknown, the ridge on which the house resides is locally refered to as Hökeberget, but the name does not appear until the house was built, why it is more probable that the house gave name to the ridge, rather than the opposite.

Hökebergs slott was originally built as the home of the rich farmer Eskil Eriksson who created a fortune through reckless export transactions with crop and whose fortune was lost trhough the Kreuger scandal. The house was empty during a period in the 1930's, before it was purchased by the retired officer Nils Ryttare. Nils Ryttare was known as Germany-friendly and during the war he invited many powerfuls Germans, including the German concul of Gothenburg to Hökeberg. It was a visit by German officers and diplomats at Hökeberg 1943 which came to be known as the "Hökebergsslott-incidenten" [Hökebergs castle incident].

Ryttare and the German friends would have been out on bird hunting when they intercected with a number of "ill-dressed men" and got into a fierce word exchange. The police was called in to chase away the vagrant, whereupon the company of hunters went back to Hökeberg. The morning after, two of the the Germans, an embassy secretary and a German flight officer, were found murdered in their bedroom in the Palace annex. Soon the "swaggers" were accused for the deed, which was presented as a burgular turned murder. Despite the Vara police arrested several loafers, no one was ever tied to the crime.

The event did not receive much attention in the press at the time, but the German Embassy in Stockholm called for a "requisite" investigation by the police and the event created some diplomatic exchange between the war making Germany and neutral Sweden.

1947 surfaced information on the role of the Germany friendly Nils Ryttare being an British agent and a source the Embassy of West Germany in Stockholm reported to [Swedish news paper] Svenska Dagbladet that the German secret service during the war had suspected that Secretary flight officer had been killed by British commando troops or the Norwegian resistance.

The first problem - there are more - is that history does not contain a grain of truth. Hökebergs castle is fake (the name "Hökeborg", was inspired by the early translation of Tintins castle Moulinsart), the only palace in Kvänum has nothing to do with it, not even the ridge Hökeberg exists, there was no such thing as a west German Embassy in 1947, etc. . Not to mention the murdered Germans.

The second problem is that the person who invented the story published it on the Swedish Wikipedia, and more specifically on January 25, 2007 at 22:51. Perhaps to see how it looked. At 22:52, he removed all - but already 22:53 a helpful user reversed the deletion! Probably in the belief that the removal was a mistake. The log files confirmed his version of the story:

The story was never more than a sketch, but after some discussion on Wikipedia and its reliability, I in a weak moment put out this sketch on Wikipedia as a proof that if we only seem convincing, people are buying into anything. Then, I got cold feet, thinking of my upbringing and that we must not lie so there and removed the article again.

A few days later I discovered to my surprise that the article was restored - and then I decided to let it remain. If Wikipedia swallowed it so easy and if they wouldn't accept my erasure they had to stand their caste.

If you surf the Web you can find some examples of people who did not only read and believed, but also conveyed "the incident". But the story was not really spread until Svenska Turistföreningen [the Swedish Touring Club] included the story in the Yearbook for 2007. The theme of the edition was "Crimes and regions", and in an article on spies, the editorial (not the writer, NB) had seasoned with some interesting episodes on the subject. For example the murders of Hökebergs castle.

Isn't it just amazing how easy you just buy into something that has a certain level of detail. It could be true, it's on Wikipedia. So it must be true. As the good man Brian Dunning puts it: Be skeptical!

Copying multiple work items between projects

I know there are tools out there for us who are migrating work items between projects but I prefer the olf fascioned way using the excel integration.

So what I do is that I use the excel integration to view the items in the old project in one excel file. I first create a query which includes the items and the columns I wish to access. The reason for me creating a named query rather than using an ad hoc query is that if something happens, you know which items have been moved and which hasn't. I most commonly move one work item type at the time, for example.

Well of in Excel I use text to columns or concatenate the content of different columns to match the new template. I always save the old work item in one column or concatinated as a part of the text in a field.

I select from the new project to Add work items using Excel and now I have two excel spread sheets. I then start copying from the old template to the new. When I've copied title and the field in which I've saved the old work item ID I start pushing the data to the server.

One of the problems I experienced was when I filtered the original list in Excel and then copied one column at the time to the new excel file. What happened was that hidden rows from the original excel file was also copied, so there became a mis match in the list. Not good. So, filter the list in TFS and you won't have to experience that. I'm just glad that I saw it at once. One trick there is of course that if you have to copy columns one at the time to keep track of how many rows you have.

If I'm just copying one work item between projects I simply use the Copy work item functionality in TFS: you can use that to copy between projects.

Australia?

Checking out Google Analytics I found that Australia is the country of most of my readers the previous month. USA has been number one since day one. Go Australia!

What do you call those individuals in the room?

Being kind of new to software development, I'm really not into what you should address people as. What I've found by just scanning employment adds is, that Programmer seems to be a title that is not "hip". I guess you call those guys developers. Or has the role changed and the programmers are no more?

Then there are the architects. I've realized that they are better payed and that "other developers" (or real developers as the other developers sometimes call themselves) sees those guys as the ones who don't crank code but spend all their days in the meeting with "the other guys", or "the business people".

Then there are the project managers. They can be developers but most of them say something like "well, I still write some code on my free time", or they just pest people about filling out their time sheets and no little or nothing about coding. But they know all about making a plan looking really smart in Microsoft Project.

Then we have all those experts, they can be database experts or usability experts, security experts or experts on some system or product. That seems to mean that they think that their field of interest is the most crusial part of the project and the others simply have no clue.

In a agile software development project, all these guys have new titles and hopefully new roles.

And how do I address the guys? Well, I call them by their christian name. Their parents gave them those, and I hope they knew pretty well what works for them.

How about titles then? I love titles. If I'm out selling I can simply put the label of Security expert or head architect on each and every one of my team and present them as such. Because in a team of peers, all and everyone should be able to take that part. Then there are some who play the part a little better than the others, but we work on that too.

So, what am I? I cannot say. I'm so glad that we use scrum so I can set a word on what I'm doing. And since my pals are either hard core agile developers or in other fields of work (and simply not interested if my title doesn't signal free computer support) that often ends the discussion.

Themes on your backlog

Since we scaled up our scrum team, we have a separate product manager, who controls the long term priorities, what we call the product road map. You could say that the product manager defines in what direction the product should evolve during the coming year, whereas I as the product owner is responisble for making a priority which makes this implemented in the best order.

The road map consists of simple terms, for example "spatial dispatching version" or "SLA support". So how do you know if we are working on the product road map? What we do is that we have a combo with the items on the road map (when you define this field, make sure that current values are accepted, since stuff will be removed from the road map - a k a from the combo option value list). The combo value list consists of the items on the road map. Defining these lists are not a one-second job. And that is actually a good thing: if the product manager want to include something on the road map, the list needs to be changed.

What we then do is that we set this value on all stories. We call the field Theme, based on the theme term used by Mike Cohn.

What we now can do is that we can track when we spend time doing stuff concerning a theme and since we have related work items in the form of tasks which have registered actual time, we can also calculate how much time and money we spend on a theme. This makes ROI calculations possible.

There is also harder to include stories which does not lead us nearer the objectives of the product road map. I don't think the field should be mandatory but if the field is left empty on a story, that tells us something too.

Should this only be set on stories? I'm thinking about also having the field on bugs: when you calculate ROI you should include all costs and that means costs for bugs. A story could seem simple and cheap but there were lots of hidden costs in the form of unfinished or faulty work (aka bugs)

Link work items or copy them?

If you're using TFS and work item tracking, you've probably seen that there is something called copy work item and something called link work item. But if you use these functions and take a closer look under the links tab, you can see that both results in a link to the original work item.

One of the differences is that copy work item copies fields which have the same name. So, if the original work item has a field called Feedback and the new work item have that field to, the value is copied. So, I've used Copy a lot of the time, to enable this nice thingy. The problem is that this causes other problems.

At my company, we use the excellent Scrum Dashboard from former Elektropost, now EPI-server. If you copy the work items, the calculations of work does not work properly. So, I'm back at using links again.

Stopped talking about usability

How often do you want to save an unsaved document when you close it? How often do you want to discard your changes? If I exclude every time I give up when the mysterious formatting rules of MS Word plays me a trick, I most of the time want to save my changes. From usability point of view, it should probably be better if my changes were saved per default and that I used another command for closing and discarding. (the example is from the exellent book, About Face 3. And yet, why doesn't this feel right?

Yes, making save when closing would exclude a lot of keyboard pushing or mouse clicking, depending on which kind of person you are. But still...

It is called expected behaviour, and when I talk about these issues with users and developers, I've stopped using the terms usability and user friendly and I talk a lot more about expected behaviour: what does users expect when they do X?

And this is the problem with the default save on close: people expect to be prompted and would probably get nervous if they weren't. This should probably be changed in future UI:s, but this should probably have to be a global change. Otherwise you get confusion. Like with the card machines in the stores where there is no standard so you have to take a look at the actual machine in the store how to draw your card. We don't know what to expect.

One example of annoyance is in Windows Mobile, where clicking the X in the upper right corner according to UI guidelines is closing without saving. How expected is that?

I like surprices, but in the form of a nice gift or a clean home when I get home, not that my document hasn't been saved.

Nothing to win and all to loose

Being a cyclist fan, I too was stunned at hearing the news that THE man, Lance Armstrong, is returning to professional cycling.

Unbelieveable. He says it's for the cancer funds he's working with. I wonder if that is enough to win. And I wonder if winning the tour an eight's time is worth taking the risk returning and loose. Being a Swede I remember Björn Borg's fatal attempt at returning to tennis. Leaving at the top was a better choice than returning to the loosers.

But what ever his end result, I look forward to watching mr Armstrong on the bike again. You might say doping, cheating, what ever. But he was a really hard working athlete who to the public never blamed anyone but himself when he failed. And being a women's lib, I can help cheering a bit more when the son of a single 16-year-old working class girl gets to be the best cyclist in the world.

Where to draw the line and developer's day off

When developing using agile methods, user and customer feedback should be important. True? And if the feedback is important, how do you make it worth while for the user/customer?

Well, if the user/customer feels that he/she is being listened to, this could make it worth while. Or?

So, it should be a good thing if the user sits next to the developer and points at something that he/she feels should be different?

Which brings us to the important phase: where to draw the line. The line between changing the scope of the task or giving input to the task in progress.

Let me give an example:
A developer guy calls over the sales person, who is giving a big demo for a potential customer in a few days. The developer shows the new form for entering orders and the sales person gives some good input on that. But then he sees that the Order form lacks support for attachments, something he wants to show the new customer. So he says:
- But you cannot add attachments. Can't you fix that?

Should the developer comply? Well, if the attachments were covered among the features committed to during the sprint start, he can say that it should be fixed. But otherwise: no.

Why? Well, it's not up to the individual developer to change the scope for the sprint or the story. It is not up to the individual developer to say that if there is time for additional features, he should be in charge of desiding what that feature should be. Or worse: if the attachments are added and other stuff is cut: this is disasterous. The product owner prioritizes new stories and features. And give the team freedom to implement those features and stories the way they feel fit. And if the stories are faulty: this should be up to the product owner to fix.

So, what happens to our developer? Well, if he complies to the sales person's wishes, what happens those few days later when the sales guy is up for a demo? Is there a slight chance he sneaks up to the developer and asks for some help getting a demo with that included? And what happened to those tasks the developer was supposed to do and which were left blocking the rest?

Does this mean that I'm a mean product owner? Some might say yes. But I think my job isn't being nice to the people who like ducking for the rules and who makes themselves and their situation "special". I'm nice to those dependant on me in that sense that I want to be able to keep my promises that we focus on the things that are highest on the priority. It is not demoing stuff one sales person found hot while others were waiting for critical bug fixes. And it's not nice when the bugs in the not so well thought through features surfaces. Because they do surface. Been there. Done that.

Complying to user input during the sprint should be aimed at solving the problems on the sprint backlog. (The developer in my case actually did stuff especially for the sales person, stuff that we had to remove to meet the delivery objectives. Not so much code in it self, but damaging to the team commitment.)

And finally: I do give the developers a day off in each sprint: after delivery they can all choose something they want to spend time on. Yes, they do have to explain what and why so we don't get the unknown code with unexpected behaviour and hopefully we miss out on the bugs.

Agile means agile, not free of charge

Agile means that you can develop more for less. Right. That does not make it free. This little film is for all you product owners and stakeholders. How does it feel for the developer, when you change your mind all the time (so the guy knows that your wish is nothing to pay any attention to, since it will have changed the next time you meet) and too late (so that the change becomes very expensive since hehave to roll back what he has done)? Change your mind, yes. But think first.

Field names when defining work item types in TFS - why this is important when you copy work items

When you have a work item and you want to relate in some manor to that work item when you create a new one (for example if you want to create a task that relates to a story or if you want to split a task into separate tasks or if you've registered a bug and realize that it's actually as designed and you want to create a story in stead.

You will soon learn that this is a common task if you keep the product backlog and the sprint backlog in TFS)

You can right click the work item in TFS (both in the query result view and the form) and select Create Copy of Work item. When doing so, you can select what type of work item you want the copy to be. So you can copy the bug details into a story or a task. This is really brilliant, but to make it really work well you need to consider what is being copied.

TFS tries to match the fields in the work item definition so if you copy from a bug to a new bug, all the fields are copied (well, not all like created date, but you get the picture). But if the work item types don't share any fields, nothing is copied. So this is worth taking into consideration when defining your work item types.

How hard can it be?

How can X take so much time? How hard can it be, I just want Y? It's just a simple Z I want?

No matter how they put it, people not directly involved in software development but who are stakeholders, or the guys paying probably think those questions. And not so few come to the same conclusion as Dilbert's boss in the comic strip.

And funniest of all is that when they are not happy with an estimate and somehow make the developers lessen their estimate: they are amazed that there are bugs. Wonder why...

I must admit that before sitting next to the people tapping in all that code, I probably thought something like that as well. But it didn't take me long to realize that it's not X, Y or Z which is the problem. The problem is that when X, Y, Z is decribed, it's described in the form of a standard process. And like all processes there are alternative paths and choices and situations. And building to handle that is hard. But in some cached mode and comptact framework and the form factor of a handheld device and you're in for a real ride.

Developers should go out to the users to understand their world, but stakeholders should also take part of the developers every day's decisions and the complexity in what you might see as a simply thingy. My boss said the other day that he wanted a butcon which did C. I said that it wasn't free but it can be prioritized. He said: how hard can it be: just put the button there and the users will be happy. Well putting the button there is not the hard part. It's a bit harder to meet the user's expectations when they press that button. Both when they are using it like my boss imagined them using it, and the ways he wasn't imagining it.

No wins yesterday

The small solution, the little company took the prize. Disappointed. But something to reach for next year.

Mobility seems still be a question of giving users a PDA. But how cool is that? For me, the biggest challenge is not saying: if you want to be mobile, you need a device of this size and Windows Mobile. All others can use standard Windows.

People in a mobile work force need to be able to choose the computer which fits their needs. Often, that is a PDA. But not always. And in our line of business: mobile work order handling, the need for laptops in the field is getting bigger and bigger. To be able to fix X you need some other Windows software. And that too needs to support the mobile scenario. Our users sometimes have a constant connection to the network, but sometimes they don't. And that goes for all the users. Supporting that scenario for different clients is complex, interesting and challenging.

Three of our boys

I don't know if they've fixed the texts, but now Microsoft has published the film with two of our guys presenting our nomination to the mobility category of the Swedish .Net Awards. Our customers are represented by one of our smaller companies and I'm amazed how good this owner of a small door installation company is in the movie.

What do I need to know about a bug?

If you're using a different work item template for your bugs, you have an oppertunity to think through which attributes a bug or a defect has. The definition we're using for a bug is that if something implemented in the product does not meet the Definition of Done criteria, breaks UI guidelines or does not follow the specs given, it's a bug. If we change our minds about the column order in a grid, it's not a bug, but it can still use the same work item template or follow the same form for describing it.

The most important thing for me and my organisation is the following:

• Title
  A short description of the percieved error. This must be readable to the person who found the bug so he can recognize it on the list and so that the product owner can spot the business value in fixing it. It must also be clear for the developer what he's supposed to fix. So, you should be extra careful in writing that short title.
  
• Description
  Since there are probably some details that are missed in the title, you should write the description to give more details to the developers, po and registrator here.
  
• Notes
  The developers need their own notes.
  
• Importance
  I use the same scale as for other product backlog items since I'm prioritizing bugs as well as stories and other stuff. I do, how ever, have a rule that have the lowest value on bugs as 1 and the lowest for new stories as 0. Why? Well, if the prioritized stuff is done, then we should fix bugs rather than start implemented new, unwanted features.
  
• Registration date and Close date
  Needed to enable the creation of a value stream mapping. I most commonly look at critical bugs and how long they are active.
  
• Status
  Not verified, Not done, In progress, Done, Draft and Deleted are the values we use
  
• Steps to reproduce
  Steps that anyone can follow to reproduce the bug. Should be mandatory.
  
• Source
  Who registered the bug
  
• Severity
  How serious the bug is percieved
  
• Environment
  Since we have hosted environment and customers who have on-site installations, this is very important
  
• Affects versions
  Versions which are affected by the bug
  

Itching

I'm hurt. I'm in pain. And the worst kind of pain: itching. The scar from the operation must have been scratched today when I was biking and now it is swollen, red and itching. Clear pain I can handle, but itching. AHHHH.

Small bugs are just like that: itching. You know that small spelling error or those labels that are not properly aligned. Or the worst: the switched OK/Canceled buttons in dialog box. The problem with those itches is that they make not appriciate the good things in life or the new funcitionality.

So: get rid of that itch. Fix the small annoying stuff. They mean more than you could possibly imagine. I can place some plaster on my itch but this is a very bad idea when it comes to the itches in applications.

Using the Excel integration for TFS

Since I'm not a developer, I've simply installed the Team Explorer on my computer. I update simple stuff directly using the GUI in TFS, but sometimes I need to make bulk updates, send info to stakeholders or make some statistical analysis. Then I use the excellent Excel integration. It is easy as pie!

• Right click a query in the team explorer and select to view in Excel.
• Select a number of items in the result list, right click and select to view in Excel

When in Excel you can change which columns are visible and make bulk updates: simply make your changes and by clicking "Publish" you can simply upload your changes to the server. By clicking "Refresh" you can refresh the items in Excel from the server. Of course you can save your Excel file and re use it if needed.

I also like using the Pivot charts in Excel to enable fast data analysis. And since it's in Excel format, I can send the files to other stakeholders.

Another nice feature is the creation of story cards. I have my default query in Excel and then I use the Mail merge features in Microsoft Word to connect to the Excel file. I can then create my own story cards, which I can print before a sprint start. I use default A4 format and a three column layout. The first column consists of the title of the story and the other columns are used for other stuff which is of interest of the developers. It takes me about five minutes to create the story cards. My biggest problem is that the mail merge wants the columns to be at the top of the excel list, which is not the case then I'm using the Excel integration. But this is a small hazzle, since I can preview example text instead of the field tags. If you're in to Postits by husband recently bought A4 size large postits made for printing.

So, why choose when you can have it all!