Keeping your stories in TFS (team foundation server)

This of course applies to other systems, we've been using story cards, Sharepoint and Excel, and the attributes or columns become about the same.

When keeping your product backlog in TFS, you can define one work item type and make this apply to all your stuff on the product backlog. As I've discussed earlier, you will probably have other stuff than stories on your backlog: you could have technical stuff as upgrading your development environment or setting up your testing environment. You could also have your bugs on your product backlog. In many templates, there are only one work item type for your product backlog item. The good thing about this is:

• You don't have to think about how to classify the new item when you're about to create them. Is this a bug, or a story?
• It is easier to configurate your product backlog queries since you're only working with one kind of work item. I know it's a hard nut to crack, but writing nested queries is never easy for me if I'm forced to use a graphical tool. TFS is no different.
• It is easier to change type and form. If you've created a work item you cannot change the work item type. Yes, you can copy to another work item, but the links are then towards the old work item...

The things that speaks against using one work item type is that if you have different stuff on your product backlog, you will probably classify these different types with different attributes. You will only have one state machine and the state options have to take all types into account. For example, if you have bugs on your product backlog, then you might want a state for unconfirmed bugs. This will probably not apply to stories. Also, it is easier for users to see what type of work item they're viewing: helpdesk might only be interested in bugs. The latter problem can of course be solved by adding a combo in which the user specifies type.

We have a specific work item type for stories. These are the attributes:

• Title.
  Short description of story in the form As a x user, I can y, so that z
  
• Description
  Notes from business people, which can help in understanding objective
  
• Definition of Done
  We have a Definition of Done written down. This applies to all stories. If this does not applies or have more things on the specific story: this will be added here
  
• Importance
  Value which only should be changed by Product Owner. We use a falling scale, in which 10000 has been the highest and 0 the lowest. I tend to use a broad scale, for example at least 9 between items (1990, 1980) to make it possible to easily slip in a new story between other stories. I can also use the number series as grouping (all stories 1990-1010 are related)
  
• Story points
  Owned by the team for their estimations (story points)
  
• How to demo
  A list of things that should be demoable
  Tests which should be performed but might not be obvious to the developer or tester
  
• State
  In which state the story is
  
• Assigned to
  This is most commonly used when a story is not understood or cannot be estimated by the team. The state of the story is then set to Draft and is assigned to the individual who will take responsibility for making the stuff clear.
  
• Sprint
  The sprint during which the story is completed.
  
• Source
  Who is the source of the story. The person who best should be able to answer questions or validate the solution
  
• PFC
  We have a product feedback center in which we log customer feedback. If an item in the product feedback center is addressed, this is entered here
  
• Epic
  
  
• Theme

I'll be going into details into some of these attributes, if there is something special you have questions about, feel free to ask

Division of labor - scaling up the product owner role

There can be only one. That is, there can only be one product owner for a product backlog and a team. You can split teams and have people part time on different teams (even if this is hard) but you must have one person responsible for the product backlog. Mike Cohn says 'one, wringable neck'.

How cute isn't that. But how do you combine a constant presence with developers to be able to make those immediate decisions with being out with the users to know what should be put on the product backlog?

One solution is the division of labor. The product owner takes responsible for stuff that is placed on the product backlog and can be up for developing. Let's say that the product owner is responsible for having stuff on the product backlog which covers about three sprints of development. The work consists of taking responsible for that the stuff describes what the users wants and is enough so that the developers can start building the stuff. Stakeholders should be able to change their mind and change the priority between this stuff without it having a huge effect. The product owner is responsible for the priority in that sense that the most business value can be built for the least cost.

But what qualifies for making it to the product backlog? In my organization, we call that role the product manager. You could say that he pushes in stuff from below. Of all those big chunks of stuff that are "in the future", which do we want to build in the coming quarter. The stories are bigger (sometimes called epics) and they are not exactly the stuff we want to build right now, but they are getting close. You can also say that the product manager is responsible for the road map for the product or the project.

What is important is that the product owner still owns the product backlog - if the epics and stories presented by the product manager isn't of sufficient quality (you don't know what he wants or the business value is unclear), the product owner must say no to taking up the stuff on the product backlog. If you have a role like our product manager, this must be seen as guidance for the product owner. For me to be able to do a good job, I need to know if that big chunk is worth more than that other big chunk. I don't have to think too much about the future, but there is someone who does.

Of course, to make this work, you need clear rules and suitable people. For our organization, the title product manager gave many an idea that this was a role "over" the product owner. That should not be the case, but the opposite is not true either. It's the perspective that differs: a product owner should reside in the present, the product manager should aim for the future.

How big are your stories?

The answer to that question is that depends. And it depends on what you are using them for. Stories that are far in the future is written to give people an idea of which stuff will be done "sometimes, but not now". These stories can be very big since if you're not going to build it, you don't know the details. That is self explaining: why would I want to know the details about stuff we're not building? But then you could say that sales people need details to be able to know which customers to target. But that problem should probably not be addressed by the product backlog, but the business plan. If you've targeted a specific client who have a specific need: simply write down on the product backlog item to take that customer into account when you're specify the details.

When you get closer in time: you break down the story into smaller stories, which can be handled and prioritized. Divide stories after the following principle:
* They can be prioritized independently - that is - they all have their own busines value
* If they are up for building in the near future, never make them larger than 1/3 of a sprint, so you don't risk having to finish a sprint without any completed stories
* Make them possible to build independently. If they are all connected and must be built at the same time, the previous advice is of no use.
* Don't divide the stories yourself: this is what you have story writing sessions for. Because only developers know which things can built independently and only the users know what has its own business value

Nice packaging

I usually hate packages. But this is cute.

Do you have bugs on the product backlog?

Mary Poppendieck says that if you're tracking bugs, you've got a faulty process which enables errors. Well, that might be true. As well as it's true that you should be consistent in bringing up your kids or you shouldn't tell lies. For myself, I hate the word bug, as I've written in an earlier post. It brings out the most evil in people. And that is blame. Well, someone made an error, so let's all find him, humiliate him and make him clean up his mess. And that him can be the uncertain requirement's guy who wouldn't give a straight answer, or the stupid developer guy who should have known better, or the idiotic user who doesn't use the program as he's supposed to.

So, let's just leave it there and say there are stuff in the system which we've already built and we're not quite satisfied with how it turned out. The changes are hard to describe in the form of a story, som we just state which part of the system we want to change and how the problem looks. For example:

• When viewing the total sum on a billing detail, the currency is missing
• When printing a billing detail, the address is not included

If it's not obvious you can also add why this poses a problem: this makes it easier for the product owner to set a business value and a priority.

So, the answer to my question if I believe bugs should be on the product backlog is YES! If you don't include them on the list, how can you possibly give them a priority? And should users track two systems? If you're into lean and believe bugs should be fixed first, well then you only give them the highest priority and then you can still give some information to your stakeholders.

Is everything on the product backlog a story?

Well, that depends... The reason you have the product backlog is that stakeholders have something to prioritize and so stakeholders get a rough sense when stuff will be available in a release.

The reason you have stories on the product backlog is that the format allows non developers to understand which user needs will be addressed. We specify who, what and why.

So to be able to answer the question if everything is a story, you need to ask yourself if everything you want to build can be expressed in that way. Of course, everything can be expressed in that manor, but sometimes it makes it just harder to read.

For example, the users wanted to switch columns in a grid. Well, of course you could write that as a story but as both developers and user understood "Change column order in usage quantity grid", why applying a format which in that case does not add to the readability.

It is often the same with defects or bugs or what ever you want to call it. I'm later going into the question if you should have bugs on your backlog (well, of course you shouldn't have defects in your system but you shouldn't have eaten that last sandwich either...) but if you do have bugs or defects on your backlog, writing them as stories probably just decreases the readability. The user knows (if they've experienced the problem) know what problem they want to be fixed.

And then there is all the other stuff. Like upgrading the test or development environment. Here I suggest a hybrid: for techie stuff: always include the why. Like for instance upgrading to SQL Server 2008: why should we do that? Otherwise non techies cannot see the benefit and therefor not rank it.

How do you estimate a release date?

If you're making relative estimations for your product backlog items - how can you possibly know when things are released? The answer is velocity. And with velocity I mean the number of story points you can finish in a sprint. And how do you know that? Experience.

This is how you play the game: You create a product backlog with a number of stories. You give each story an estimate.

What happens next is up to you. You can try calculating a velocity by turning to the good old Golden list and look at the items there: how much work was put into those actual tasks? You will probably need to recalculate if it's a different team or if other stuff has changed but since you're in to software development, the maths are probably not your softest spot. So now you have an appropriate number. Say you looked at some items and find out that based on the team and sprint length and all those factors, a figure could be 27.

Ok. 27. Do you believe that 27 is what the team can accomplish during a really bad sprint, an average sprint or a brilliant sprint? Place that number in the appropriate box and simply guess what the number based on that should be on the other types of sprint (bad, average, good). You can of course ask some other guys as well but now you don't know too much. You don't know how well the team works together, if the development environment is good, if the customers and stakeholders will deliver material in time and all that stuff. And what you do now is get the people responsible together and ask the simple question: will this be worth it? You can now from your vague intuition on scope and velocity give a very very rough estimate on how much everything will cost and when you'll be done. If people still are on the train, you can get going but this is a very important time because now the people paying the bill can see some kind of prognosis of how huge this project is. And how much it will cost.

If they are still Ok with paying the bills, you can start your first sprint and this is the first oppertunity for changing your rough plan because now they will commit to the stuff on top of the product backlog and now you can see what your 27 was worth. Let them take on what they feel they can handle. Don't push them to take on more. Don't hinder them if you believe they've taken on too much. Let them commit.

After that first sprint you take note of the number of story points finished during the sprint. And you do the same for the coming five. And now you can really start to get a feeling for your velocity. Take the lowest two results and take the average. This is your minimum. Take the middle two and do the same. This is your average. And then you take the top two. This is your max. For example:
22
20
28
30
12
40

This would give you a min of 16, average of 25 and a max of 35.

OK. What you do now is that you go back to your product backlog and then you look a head for the next 4 sprints. And you see how much lies under 16*4. This is what you can count on being fixed during the next four sprints. The stuff that is under (25*4)-(16*4) is decreasingly probable that it will be fixed and then you can just increase the improbability. What is over 35*4 is certainly not going to be fixed, if nothing else changes.

So what you can do now is go to your stakeholders and present the information just like this: this we will do, this can be done and this will probably not be done. They will probably change their priorities a bit and this is the objective: getting them to decide how sure they want to be to have something within a specific time frame. And to understand that this is a numbered list: if something goes up, something else drops down. Working like this makes it obvious and if it still isn't to your stakeholders, use some visual effect like postits that you move up and down to make it clear what prioritization is. The hard part is not saying what you want but saying what you don't need as much.

Estimating the product backlog items - why using a relative scale

Why do you estimate? I see two big reasons, which are connected:

• You want to build the most business value for the least resources. Therefor you need to know how big stuff is so you know if it's worth it.
• You want to know when new or improved features can be put into production. This so sales people can sell them at the right time and the users to prepare (for example education, integrations and installations need to be planned).

If I were asked how long it takes to build a house of cards I can give you an estimate I could give you one in a second. And so can most people who know what a house of cards is. But if you have a room of 30 persons, you will probably get very different answers from most of the people. Some of the differences lies in:

• Perception of what a house of cards means. It could be two cards or it could be a deck of cards.
  
• Skill in creating houses of cards. Some people are good or skilled at it. Some are not.
  
• Difference in how you measure time. Is it an empty room, no one around and you get to work by yourself? Or what. This gives huge impact on the estimate.
  
• Tools available. If you're allowed to use glue or cards appropriate for building houses of cards you would probably give an other estimate than if you were using some old weak deck.

The list goes on and on with all those little things which affects how we give estimates. So, what can you do? One solution is getting better information. You specify exactly what you want and what the pre requisives are. What is wrong with this approach: well it takes too much time and it makes changes impossible. If you make one small change, well then the estimation falls. The only way to make a good estimation using this approach is building the house and afterwords saying how much time it took.

So, what can you do? Well, what you can do is look at two rough sketches of a house of cards and then ask: which one will take the longest to build? Do you think that it takes double the time or tripple the time?

It is probably hard to say it's 1,3 times harder so you need a scale which you can discuss from. A popular scale is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. And of course the higher the scale, the more insecure is the estimate.

Estimating using planning poker is fun, fast and amazingly accurate. I will not take trouble trying to explain it, because the Swedish consultant firm Crisp explains it much better on their web site. There you can also buy decks of cards (even if I love the Mountain Goat Cards). What I do miss on their page is the use of a Golden List. The Golden List is an example list of estimations. You identify a story of each size. By doing so you can ask questions like "well is it really twice as big as X". The Golden List should be made up by stories which you've finished but if you're starting up you can fake a list from previous projects or simply things people can relate to. Print the Golden List on a big sheet of paper and keep it visual during the estimation session. Break when discussions are going into hours and days: keep comparing!

But hey, this only answers one of my needs: the possibility to compare size to validaing we get the most business value for the least time. How do I know when things are released?

Where are the details in the story?

When I read a story to my son, I don't have to tell him all the details because he uses his imagination to fill in the blanks. And the amazing thing is that the details are just magnificent. Some of us oldies have the same objections to Lego. When we were kids there weren't all of those special parts but you could use your imagination to make those standard parts all the cool stuff we wanted to create or simply play with.

Working with stories like "As a mobile client user, I can book my assignments so that I don't get double booked" is some what like working with standard Lego. Mike Cohn says that a story is a placeholder for a conversation because if you drop a story like that on a bunch of developers and then run as fast as you can from the project, of course you won't get what you want. Just like dropping a handful of Lego parts on a kid and expecting him to build what you want, without direction.

So, a story needs to be completed with some direction. And this in the form of a conversation. If you're building a puzzle or completing some kind of model or Lego structure right from the box: what do you do? Well, most of us look at the completed picture to know what we're aiming for. OK: we're building a space ship. Cool!

Why do Lego use pictures as instructions? Just imagine building a Lego Space ship from a written description. How good are your chances at getting that right? And how much time is spent on trying to understand the text?

When you write the story: you draw the big picture and then you go in to details. Well, We're going to need some landing gear. And then we can get into all those details for that part. So, keep the story short and add details as you go along. When you need them. And when you have enough to make a decision.

But does that not mean that I have to be around those dev guys all the time? well, not all the time, but a lot of your time. If you are the one who can make decisions. For developers make those decisions if you're not there. Or they stop working.

But how can you estimate that story stuff? Sounds crazy. Well, back to my Lego. How long does it take to build that space ship? Well, even if you have the detailed spec and read from that and then give an estimate on how much time you will probably be wrong. And if you have kids, they will disturb you or wreck the stuff while you are working.

But what you can do is that you can take two lego models, look at them and say which one will take longer to build. You can probably say if one is double the effort. But if the model is huge (full size Cottage) you have no idea for it's is simply to big to estimate. And this is why you don't estimate stuff on the product backlog using actual (or as I call it: inaccurate) time but using story points. She's just getting more and more vague? Or... Get back to you!

How do get some user stories on your backlog?

Believe me, I've tried all possible and impossible ways to get those stories printed. They all suck, in some manor. There is probably no such thing as a perfect solution. So, just drop that wish, and just try make the best of things.

The reason for writing in the form of a user story is that you want to catch the objective - what need do you want to forfill. Keep that in mind.

But then, take one step back and think: why do you need a product backlog? Well, you need to be able to tell the developers what they're supposed to build and you need to tell the users what they are going to get. And the things being done should be the thing that brings the most business value.

OK. Who should participate: well, first you need the guys who knows how to define the problem, and then you need the guys who are going to solve the problem. This means that you need some (representants for) the users and you need some developers. And then you arrange a story writing seminar. A story writing seminar means that developers and business people/users/stakeholders get together and try to get the problem needed to be solved printed in some form (digital or analog). If you are many: divide into groups. If you don't want to spend to much time: time box and keep the meeting standing.

I'm often asked: why involve the developers? Shouldn't they be coding? Well, to which use is the code if they don't solve the problem, and how great is the risk that they build the wrong thing if they don't understand which problem they are solving. That's why both groups are involved.

To make the meeting more focused and to have something to discuss around, I've created example scenarios. It's max 2-3 pages long and describes the types of users (personas are great for this) and what the surroundings for the problem is. For example, we're working in the field service management product business and an example scenario can be the small electrical firm who wants to report new cases while in the field.

All that want to participate need to read the scenario in advance and we spend perhaps two hours writing these short stories in the form described in an earlier post. But then you say: what about the details? That was like one sentence. That couldn't be enough for developing or estimating? Or could it?

What can you find on the product backlog? Part 1: the user story

When you know what the objective is, you can start making a list of what you need to forfill that objective. This list is called a product backlog.

So, to be able to answer the question what you can find on the product backlog, you need to know what you lack to meet your goal.

There are many ways to form a product backlog item. I like user stories. This is a good form for a great part of the product backlog. So, what is a user story? The basic is that you specify a kind of user, what he want to be able to do and if it is not self explaining: why he needs that.

To be able to specify a user story, you need to know who are your users. You can use personas or you can hold a seminar with stakeholders. The important thing is that everyone that reads the product backlog should be able to understand which kind of user you are talking about.

For us, that has resulted in an hierachy of users and user groups. We first have the basic User, who can be anyone from an end user to our developers. You can say "everyone with access to the system". If you then take that general user you can divide him into different categories, for example after skill (first time user, experienced user, user with hearing disability, expert user), client (integration, mobile client, web client, windows client), access rights (basic rights, administrative rights) or user type (helpdesk, technician, super user, operations technician, developer) or a combination of many of these traits.

Why you specify the user type is that it is made clear to everyone for whom you're building and for whom you are not building. This does not only make it more clear to the developer how UI should be formed but also how business value is calculated - if the sales division wants to target a certain group the business value of stories targeted at that group can be lifted. It is also tactical to give different groups "something of their own" from time to time to make them feel prioritized and seen in the project. It also tells the developer whom they should ask for details - if the user with poor sight is targeted, well, such a user should be able to give some input!

After you've specified user, you say want you want built: for example:
As a mobile client user, I want to be able to view a case address on a map

If it is not self evident why a mobile client user would want that you can add a specification why:
As a mobile client user, I want to be able to view a case address on a map so I can find my way to the location

That is how easy you write a story. But who writes them and how do you store them? And where do you keep the details? To be continued...

I didn't know it would be that hard...

Following my son the 300 m track (he was running a race for kids that afternoon) in my costume, I realised that it would be much harder than I'd anticipated. The belt made it hard to breath and the cloak made me back heavy. So, I had four hours to let it sink in: this was going to be tough.

The first 4k was fun, besides me becoming thirsty and increasingly warm: I had to have a thin cotton costume under the armour, since it would give me a serious rash otherwise. And this was a rather warm evening.

Soon after, my short breaths due to the leather belt made my tummy muscles started feeling sore. And I had all the hills in front of me.

Finally, it was all about enduring the pain. The large crowd made it possible: a Swedish movie about a templar knight made me an easily spotted figure so there were lots of cheering. And is what the costume class of the race is all about.

The final 2k, I could hardly breath and I was very hot and then, of course, a reported pulled out a microphone and stuck a camera in my face. I don't quite remember what I said, but they probably cut that part since they probably thought I was drunk or something.

But then it was over, and yes, I will do it again. Not as a knight, but as something else. And perhaps some of my friends has the nerve to make the run wearing a costume as well. I kind of like the multi person customes.

Getting started as a product owner

When getting started as a product owner, you first need the product vision. If you don't know what the vision is, how can you calculate the business value?

So good, so far. Then it's time to get the first product backlog started. You don't have to change tools, so don't be afraid to try something and later on change to something else. But don't choose something that does not fit you. As I've mentioned before, Know-b/pesters were on and on about postits and I tried it, hated it and dropped it. My advice is get a list of what your needs for a product backlog is and choose the best tool which meets the needs. Today, I'm using TFS because it meets the following

• able to visualise for stakeholders (excel integration, web access, etc),
  
• can specify my own columns (getting back to that in a later post),
• tool that developers are already working with
• tool which visualises how the sprint is progressing ( Scrum dashboard)
• able to look back on history (see how a previous sprint went)
  
• able to create delivery notes (through excel integration, mail merge in word and Sharepoint)

What I don't get is a treeview of stories (Epic-->Theme-->Story - get back to those concepts later) but the next version of TFS should include that. I've also seen on Codeplex some solutions for that. It is not that important right now and with the Excel integration and Pivots in Excel, I've met those needs as well.

So, just decide on some form for your product backlog, and then you can get started. But hey, what does the product backlog contain? well, I'll get back to that later. Right now, I'll need to prepare to conquer Södermalm. The crusade commences tomorrow evening.

Running a race tomorrow

Tomorrow evening it's time for Midnattsloppet, a nightly 10k run in central Stockholm. Like last year, I'm going to wear a custume. I had some kind of promise from a couple of friends who were coming with me but I'm not surprised to find myself alone wearing the costume of the Knight's Templar. Well, it's their loss. I'm going to have a wonderful time. I hope.

Silver for Sweden

Hurrey for Gustav Larsson and Emma Johansson. Isn't it just wonderful that a small cycling country like Sweden getting two silver medals in the Olympics. And those are the only Swedish medals up to now? Hurrey for Gustav and Emma!

There can only be one

Mike Cohn said that he seldom participate in a project where he'd found any use for digital tools for handling sprint backlog, sprint burndown and product backlog.

I've heard the same on multiple scrum seminars and even heard the phrase 'Oh, you have so much post its, you must be really agile'. As if there where some kind of corralation how many trees that need to be killed and how agile you are.

But the strangest thing is that the same persons who talk so warmly against our forests are often good at showing burn downs from Excel. I do not understand that. If the horrible truth isn't that many using postits also keep the info as a list in excel.

My experience from keeping double records of lists that changes all the time is that one copy is never up to date. And there is something that is more dangerous than lack of visualization and that is visualization of old or wrong data.

There can be only one! That is true not only in the 80's block buster. I want my stakeholders to be able to see the one and only product backlog or burndown. And since my boss wants that diagram in Excel and since we have developers who needs to work from home from time to time we can't keep postits visual to all users. Well, we could place a web cam in our team room but that does strike me as a really weird solution.

My team's main reason against using Team Foundation Server for keeping the backlogs was the visualization but the introduction of Elektropost's Scrum Dashboard even the most stubborn has accepted the solution and we've also started an interest in our services organization. I would really like our consultants tracking their project in such a tool and also visualising it for the rest of the company. And why not the customers?

Defining the team roles - going scrum

This only applies if you're using scrum or a scrummish development model...

There is so much good literature on Scrum and just by googling it, you'll find loads of definitions and good advice. My advice is: keep it simple. Use the basic roles. See the roles as such and not individuals. Get everyone to understand what the different roles are responsible for. Select the best for each role.

Keep it simple, use the basic roles
Don't try implementing a lot of your own roles. Product Owner, Scrum master and scrum team. That's it. By for example including different proxies and stuff, the roles get more and more difficult to understand. For example product owner: if you can't take the responsibility, don't take the role. It doesn't get easier by adding another role. You're still stuck with the original problem which in that case is lack of responsibility.

See the roles as such
I'm just product owner when I'm acting product owner. When I'm off, someone else has to play that role.

Get everyone to understand the difference between the different roles
If your team and stakeholders don't know the difference between the scrum master and the product owner, you loose. It's not the most important thing what you use as definition, but make sure everyone understand and respect that difference.

Select the best for each role
Well, since Greg is XCY, he must be the product owner and since Gladis used to be a project manager, she'll be scrum master. Bad, bad choice. Or, to be correct: wrong given reason. Look at the different definitions for each role and choose the right person. While attending a product owner course for Mike Cohn, most of the participants said that they didn't have the time it took to forfill the role. So, why did they take it? Pride? I've heard somewhere that about 60% of all scrum projects fail because of a failing product owner. Hope they are proud to be part of that statistics.

A good product owner needs to be able to make decisions, stand by those decisions and be there for the team.

A good scrum master must be able to know when to open the door and when it should be shut.

A good scrum team member can commit to working on the sprint backlog and forfill the tasks taken.

Step 1: what is it and what is it not?

Before you write one line of code, you should know what you're building? Well, that does not sound very agile, does it? Well, this is not getting into details but creating a product or project vision. The question that needs to be answered is why are we spending all this money and time? What is the objective AND what is NOT the objective. My experience is that besides the most simple solutions the problem is not saying what you're building but drawing the line: here but not beyond! Using the Moore template for a project vision is a good idea. Getting all the known stakeholders together and just specifying it. And don't settle for a novel. When I first asked the original product owner at our team for a project vision I was handed a A4 tightly written sheet. But even so, the limits where not included. It is hard for a salesperson to say which customers we don't want or which processes we won't support.

But this is not a one of occasion - a project vision should be specified for each bigger release of a product or in a project. If you find the Moore project vision boring you can also follow Mike Cohn's advice and produce a poster or a box - if we were packaging this release in a box, how would that look? Force the participants to use the marketing form and don't settle for a simple list. The box or the poster should be able to sell the release to new and old users: why should I buy or take the trouble upgrading?

But shouldn't you select iteration lengths, PO, scrum master and so on first? Well, how do you know who makes the best PO before you know what you're building and do you know which resources are the best? You probably have a good idea before but hopefully, this will make it easier.

The project vision should be something the developers can look at when making the small decisions: how does this bring the project/product closer to the objective. It is easy to aim for a goal but easier to miss it and often enough being close or being very far off is as bad. This is not true for sports like football. By setting a project vision, people hopefully know which goal they should be aiming for.

Is it a project or is it a product?

For me, working at a product compay, I had big problems when reading literature on software development. Everything concerned projects but we have a product. Big difference. And yet not. I believe that you, indifferent of you working in a project or working with a product, benefit from taking both perspectives.

With that I mean that sometimes you should look at your work as part of a project and sometimes you should see the product. And if you look from one of the perspectives, you should try switching to the other. Just to see what you are missing.

For example, if you're working in a project to implement a new software to your organisation and you're discussing deployment. Think of it as a product. Think how you're going to handle updates, bugs, new versions of components, etc. Think of implementing the software at multiple organisations. This might not be the case right now, but what if the organisation buy another company or is split. I don't say build for that scenario but it gives interesting thoughts which might change your priorities. And also, the users might not understand that something like that could be a problem and there is really a plan to implement the system on another team. Yes, we're doing Boston now but we plan to move on to the Dallas department later. No problem? Well, what if both have installed but want to run different versions or have different environment to deploy on. Building for operations was not the reason for me going into the software industry but that is really what makes it hard and interesting. It's not like in the good old days when the big system was built and it hanged on until it died and was replaced.

The project view is good when applying agility: if you're working at a product company you might not see the end of it. What is a product burndown chart when we don't know how many versions we're going to build? Well, in this case I see every release as it's own project and if I just focus on getting that to work, that is something I can handle.

Back on track

I didn't realize that it had been so long: I the sort of person who either does something or I don't. And I haven't been blogging for ages. A little comment on the blog made it so clear and I've decided to get back on track. I'll be focusing on implementing scrum and agile from the product owner perspective: product company style. Since last, I've changed my mind concerning a lot of things. But I still love using TFS for my work as a PO. Thanks, Andrew, for giving me a kick in the butt. So the answer to your question is that it hasn't been high on the product backlog. Or I've just been plain lazy.