When technology rule the development

I guess few people in the industry are uninterested in technology, gadgets and things. I guess the interest in system development in many cases derive from an early interest in the gadget Computer. Embracing new technologies, tools and versions are often good for the creative process, and for productive environment, but this must be prioritized like everything else. The costs must be calculated as well as the benefits. A software project is not about letting the developers have a nice time playing with the newest toys on the market.

This is perhaps best illustrated in the story of The Works. The Works was supposed to be the first computer animated film. Ten years after the project started, they were still not done and one of the main reasons was that the developers too often got new tools and versions and felt that they had to start all over. When the project was canceled in 1986, only a few minutes of actual film had been completed. Another reason for the project failed was that the technology was not ready for what they wanted to do. And that is also an important lesson: only build what you can complete.

But don't forget that most developers are interested in the new things and don't say no to everything. But estimate the costs and benefits and put it on the list. Also, introducing the "new stuff" can be an excellent reward for a hard working team after they've accomplished something grand.

Thanks Hexmaster of Faktoider for sharing the story (here in Swedish).

Cost Value Curve

Reading about Kanban, I've stumbled on this nice article on scrum and kanban in gaming industry by Clinton Keith. I know that the gaming industry is very different from other software industries, but since the author is very good at pointing this out and stressing the specifics of his industry, it's not a problem. So, it's a very good article, which I recommend.

But I did react to this simple diagram. It states that you come to a breaking point where added costs don't add so much more value to the customer. I believe that it is somewhat true, but there is a greater challenge to the product owner than just spotting the breaking point. All costs are not created equally.

Que?

No, what I mean is that if you have a functionality X with the requirements A, B, C and D which for just simplicity reasons are as costly, they probably do not add equally value to the customer. It might be that D is what makes it all worth it - for the actual user. I've often seen projects where the thing that makes it all worth while is cut. "Now we've spent enough on X so D have to wait".

And more often than not D is not the most costly feature. More often it's the feature the less vocal user identifies but does not stress enough. And not seldom it's the stuff you hear responses like "well, they'll get used to that" or "it's a learning issue" from someone who does not understand why this is important. And it's often the stuff that when you do implement it is hardly noted since it is taken for granted. So we return to expected behaviour. D is the stuff which makes X have an expected behaviour.

So how do you work this? Well, one method used by for example Mike Cohn is that when you calculate business value you don't just calculate how much value a feature introduce, you also calculate how much it costs when it's not included. D might not bring so much business value but it costs a lot if it's not implemented. I think this is one of the best methods to give room to usability issues. For more on this subject I recommend Agile Estimating and Planning by Cohn.

Linking tasks in Microsoft Project

In my series on how to use Project as a product owner blessed with Team system, I've come to links!

Everyone that have ever used Microsoft Project soon discovers that you can link task. The first method used for most users is probably dragging the bar of one task to the bar of another task.

What happens when you do so is that the field Predecessor becomes filled in. And for the more advanced users there is also a Successor field.

• Predecessors
  The ID of tasks which affects the current task
• Successors
  The ID of tasks which are affected by the current task

When you double click the link between two tasks, the Link Task dialog box becomes visible and in this you can control the link. Let us say we have task A and task B. You can find the ID of A in Predecessors of task B

• Finish-To-Start
  The finish time of Task A affects the start time of B. This is the default link and can be translated into "The finishing of The foundation of the House controls when we can start the work with The Walls"
• Start-To-Start
  The start time of Task A affects the start time of B. This can be translated into "We cannot start testing before we've started developing".
• Finish-To-Finish
  The finish time of Task A affects the finish time of B. This can be translated into "We cannot stop testing before we've stopped developing".
• Finish-To Start
  The finish time of Task A affects the start time of B. This can be translated into "We cannot stop using the old system before we've started using the new system".

When you changed the link type you can see this in the Predecessors field: 3SF means that a task cannot start until task 3 has finished.

To make it a bit more complicated you can also add a gap. A link with a gap can read 3sf+3d. Observe that if you're using gaps you need to specify link type. Remember that all units possible on Duration is also valid on gaps, including Elapsed. And gaps can also be given in negative numbers (3SF-3d) But just to give you an example on the most common settings:

• 3FS+3d
  The task cannot start until three working days after 3 has finished.
  "Three working days after delivery, operations can start upgrading."
  
• 3SF+3d
  The task cannot finish until three working days after 3 has started.
  "We need to have the old system functual three days after the new system is operational"
  
• 3SS+3d
  The task cannot start until three working days after 3 has Started.
  "Three days after we've started developing, we can start planning for new sprint"
  
• 3FF+3d
  The task cannot finish until three working days after 3 has finished.
  "Three days after we've finished developing, we can finish testing"

But why not simply drag the tasks in the calendar and not link? I'll get back to that!

Specifying duration in Microsoft Project - working with elapsed time

One of the errors newcomers to Project do is that they do not grasp the difference between Work and Duration. Not so strange, since only the Duration column is visible in the Gantt chart. But Duration is the calendar time between a task starts and the time it finishes. Work is the man hours spent on the task. You could say that work affects the costs of the project and duration the length of the project. On my post on task types you can see how these fields works together. But back to Duration.

Duration is the calendar time and when you set this on a task you type in a number and a unit. The units can be minutes, hours, days, weeks and months. How you print in the unit depends on which cultural version of project you use. For example you can type in t for hours in the Swedish Project but you need to print h in the English. Also, remember that m is minutes and yoy need to type something longer (for example mon in the English project). Be sure to check the metrics used in your version!

If you set the Duration of a task to 7 you can see that there will not be 7 calendar days between start and finish. There will probably be 9. Why? Well, by days Project means working days. If you go to Tools-->Change Working time you can see that Saturdays and Sundays are non working days. This means that the tasks will proceed during these days but no work will take place. If other days are marked as non working days in the calendar, they too will be skipped. And remember that if you mark days as non working for a specific resource, they will be skipped on the tasks where the resource is set.

But then there are tasks which work will commence independant on if it's working time. For example, I want to give a customer 14 days to think something over. Or concrete dries in a specific time. What I can do is that I can add a e in the English project before the metric. For example 14 ed. Remember that the e is dependant on which version of Project you are using: in the Swedish version you type in a t instead. The e stands for Elapsed and means that work will take place 24 hours a day, 7 days a week.

Working with part time resources and focus factor in MS Project

I dislike UI and programs which are not working in a predictable way, but then: who doesn't. What I can't stand is when the built in help doesn't help or gives me the wrong information. And Microsoft Project on part time resources is a good example on this. So how do you work with part time resources and focus factors under 100%?

Getting started - setting up the project
First, when you start up a new project file: go to Tools-->Settings and activate the tab which specifies working time. There you can set the number of hours on a day, the number of days in a month and so on. Change these to your likings but make sure your calculations work together: Project will accept settings that does not make any sense together. So, you also need to set the default start time and default end time. This specifies what start time and end time a new task will have when you create it. This is by default set to 8:00 to 17:00. So an example of good settings are:

• Hours per day: 6
• Default start time: 09:00
• Default end time: 16:00

If you only change the hours per day setting to 6, you will see that linked tasks will start behaving strange. Since a task consisting of one days work leaves 2 hours every day the next task will start the same day as the previous. Believe me: change hours per day and default time.

After the changes have been confirmed, it's time for a visit at Tools-->Working time. Here you should select the headings for Monday-->Friday and change the settings to the same settings you set on default start time and default end time. Why? Well this settings is when the resources CAN work, the default start time and default end time was how the tasks where created.

So, now you've specified the default focus factor of the resources and your project. Now it's time for the separate resources.

Setting the focus factor of the resources - part time resources
When you view the resource list in Microsoft Project, there is a field called Max Unit, and when you read sloppy documentation on Project, they state that this can be used for setting if a resource work part time. Well, not part time as I know it. Here's how it works:
When you choose Tools-->Working time, you can use a drop down and select your resources calendars. All resources have their own calendars and this specifies their working time.
What the max unit settings under Resource list specifies is the max value of unit on tasks (see my post on task type for info on unit) on a specific moment a resource can have before he becomes over allocated. This is when his post in the resource list becomes red. For example, we have two concurrent tasks with the same resource allocated:

1. Unit: 50%
2. Unit: 50%

This means that you have two concurrent tasks which the resource spends 50% each on. If the Max Unit of the resource is 100%, this will not be an over allocated resource, but if the Max Unit is 99% he will be over allocated.

This far, it seems like a good solution for part time resources but the problem is that Microsoft Project does not care if the tasks are 5 minutes long or a month. In other words, if you have a resource with max units 50%, he can only participate in a 1 hour meeting with a focus factor of 50%.

So, what do you do with part time resources? Well, you need to change their working time using their calendar. For example, you can set that they only work afternoons if they're working 50%. And you keep Max units as it is since Max Units sets percentage of the resource's calendar. If it becomes hard to visualize which resources work part time, you could take the time creating calendar templates for part time resources and setting those on the resource.

So, how do you use Max Unit? Well, if you have a resource group with interchangeable competence. For example if you have a group of three testers. You are not interested in assigning them to specific tasks, then you can create a resource called Testers and set Max Unit to 300. By doing so, you can say that we can assign three individuals at one specific moment.

Task type and Effort driven in Microsoft Project

I usually do not do Microsoft Project any more, but since there is a Project integration in TFS, I sometimes get some questions. And since people use MS Project, they fall into the task type hell.

When you work in the task views like Gantt Chart you work with the task table in the project database. In this database you have three, connected, fields, namely Work, Duration and Unit. Connected by a formula. Namely:
Work=Duration *Unit
Work is most of the cases have the metric Hours, Duration have the metric Days and Unit % (even if these are settings found in the wonderful Settings dialog box under the Tools menu). So one example can be:
80[h]=10[d]*1
Which means that if one person works full time during ten days this results in 80 hours work. So the definitions of the fields are:

• Work = man hours to be spent
• Duration = number of working days between the start of the work and the finishing of the work
• Unit= Percentage of time spent on the task

If you question my using the 8 hours a day, this is the default setting in Project. And yes, you can change this too.

If you want to try all of this stuff, you need to show all the fields in the view: the easiest way is right clicking a column name and inserting a new column. Select Unit and Work (you need to do this one column at the time) and since Duration is visible by default, you now get the complete picture.

So, now you can start playing around with the figures. (One tip though, never add Work before you set a resource on a task, then you're in for a real challenge. And also, never set a resource on a task with sub tasks. But now, back on track).

When you start changing the values in one of the columns, you can see that the other values change. But how do you know which one? Well, on the task table there is also a field called Task type and this value specifies which column should not change when you change the other values. This means that if you set this column to Work, the Work column will not change if you change Unit or Duration. Get the picture? If not, e-mail me.

What you also can remember is that there is another column: Effort driven: if you set this column to Yes, adding new resources will divide the current work on the task between all the new and current resources. But is that not always true, you think? Well, imagining creating a task for a meeting. If this task has Effort driven set to yes, adding new participants decreases the length of the meeting...

So, what should you choose? Well, you choose depending on task:

• Work
  When you know how much work will be spent. Often used for development tasks when you have an estimation in hours (this will take me 40 hours to program)
• Duration
  When you know how much calendar time a task will take. All meetings for example. And tasks where the estimations are in the terms "it will take us three weeks to be ready". Should always be set without Effort Driven
  
• Unit
  When the focus factor of the participants cannot change. When you have a resource on 40% and this will under no circumstances change.

When creating a project file, be sure to have these columns visible so you know what you're doing. And if you know that you will only use one setting, please free to visit Tools-->Options to set which setting all new tasks will have.

Sprint backlog items of type Bug and Work item type Bug on Scrum dashboard /Conchango work item template

As I've discussed earlier, we're using the episerver scrum dashboard and while testing today, I've found a small issue for my team

If you haven't used the dashboard, it's based on the conchango work item template and it have a number of work item types, for example product backlog item, sprint backlog item and bug.

Product backlog item: stuff on the product backlog

Sprint backlog item: tasks to be performed during the sprint

Bug: bugs or defects

When you set the sprint on a product backlog item, this becomes visible on the scrum dashboard (the column on the left side). You can do the same with a work item of type bug: it then becomes visible on the left column)

You can then click a product backlog item or a bug and select a number of tasks: one of these being create related bug. But here is the trick: this is not a work item of type Bug, this is a sprint backlog item marked as a bug. So if you use the reports over active bugs these bugs will not show up. Why? Well, if the bugs are a result of defects during production you will probably not that those show up in release notes and should not clog up the statistics: when you look at the bug reports these are bugs in production. In other words:
* If the bug never makes it to production, it will become a sprint backlog item of type bug
* If the bug is spotted as a part of delivered functionality, it should be reported as a work item of type Bug.

Hard to understand? Well, I know my way around the work item types by now so I can understand it but how can I possibly explain this to a new acceptance tester. And how should this person be able to know if it's a Bug or a Sprint Backlog item of type Bug? Another problem is that you cannot report Work items of type Bug using the Scrum dashboard: you have to use the web access or ordinarie Windows client.

And also, if you have reported a sprint backlog item of type bug during the sprint and the problem is not addressed, you must remember to create a linked work item of type Bug.

(And don't hit me, I didn't come up with this solution)

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.

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.

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.

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.

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.

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
  

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!

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

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

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!

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...