How can I add style rules to give visual feedback in TFS Online regarding untouched working items?

I love design and I love visual reports and alarms if something is failing. I do not love text reports though they don’t give much based on real time information and you must read lots of text to say some few things. That’s one of the biggest ideas I love about Kanban boards and the creativity for teams to make it more self-reporting by look at the board.

In this blog-post I will give you a tips how you early can indicate if a user story hasn’t been change for a while. Let say you have a velocity of doing x-total user stories a day. Something happens on the way and you want it to be visual for the whole team.  Maybe you thought you could handle more user stories than predicted in the sprint? Or in your daily work? Maybe you have spent to many days on a user story without anything happens to it and want to indicate a visual risk?
And to indicate this you want the Kanban board to tell you early that you might be in trouble so you can fix the problem early in the iteration.

You can simple visual this by adding styling rules in TFS Online that change the color of the User Story or the Task if you want to.

I my case I love the idea to indicate a warning if the card hasn’t been processed for a while. First I want to indicate it with orange color that tells me: “Hey, we might be in trouble here, but we are not in the critical state yet! :/ And I also want to know if my User Story is in a critical state. “hey, dude this User story takes too long, there is a high risk here! 😛 ”.

3
Like this image above.

TFS Online does not have all the feature I wish for when created this blogpost. So I will use the “Changed Date” attribute on cards. What I really wanted was some kind of Deadline Attribute. If using #NoEstimate and 1-2days UoW (Unit of Work) approach it could be set to 2 days from the date when you approved it, and start working on that item. Or if using Scrum Model and add estimated times on the tasks you can set the deadline to the time summarized by all the tasks and some extra risk factor if wanted.

I used LeanKit before and added deadline to cards that the customer needed to handle before it was in the Definition of Ready State. To let them understand that something needs to be done in two days, if not we need to put it back to the backlog. Or a deadline for people that love to compete with them self-regarding their own task in a more “Gamification at work” way. Or if working with other stakeholders like integration partners and need to push them to be done with some tasks before a certain date, though they had not the possibility to go full agile with us.

0
This is how it looks like in LeanKit if the end date is near. It gets yellow. If not, it’s white and over time it’s red. I love those kinds of Visual Elements and LeanKit have many nice features for it. So let’s hope TFS Online soon will have too.

To add similar rule, you simply go to the board settings.
1
After that I added two rules.
I called them ”to Late” and “Out of Time”. The naming can be something different I just used them for this demonstration.

2

In the Styling rule I used the “Changed date” and @Today syntax. @Today is just the date of the actual day. You can use more advanced attributes if using TFS on premise.

For the “Out of Time” I added the orange color and wanted to get indication if the item hasn’t changes within a day.

Changed Date <= @Today -1

2a

The Card will indicate change when it’s moved to different states, when text is changed etc. But sadly it will not trigger changed date if a related task has been changed, and that’s sad though in Scrum projects you mostly work with many tasks for each user story. And it would be nice to indicate on the User Story level if a task has some rules you missed.  Eg. You might have forgotten to change the remaining time, and to indicate on the user story level that something is wrong would be a nice feature to let developers know that they have missed this. The remaining time is important for the burn charts etc.

And for the “to late” I did the same but red color and -2 days.

Changed Date <= @Today -2

You can have higher numbers if you like to. I just add -1 and -2 for the demo.
2b

And here is how it can look like in action.

You got the warnings. One user story is near critical state and the other one is already in critical state.
As soon you move the card it will change the date and the result will be normal again.

34

Have fun playing around…

More tips:
How to color a card based on Tags or Title containing some kind of texts:
https://rockjohan.wordpress.com/2015/10/09/how-to-color-cards-in-microsoft-tfs-online-like-add-color-to-a-lean-hypothesis-card/

How to add DoD (Definiton of Done) you your columns in TFS Online
https://rockjohan.wordpress.com/2015/10/04/definition-of-done-dod-in-tfs-online/

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden.
He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated two time as the top 100 developers in Sweden in the Swedish version of Computer Sweden.

Twitter: @johannormen

#NoEstimate, successful projects in an agile world. Part 1.

It is known and has been documented that up-front work rarely delivers more than unnecessary time spent in our IT projects. CHAOS Report 2005 showed that this traditional approach was not viable. Approximately 16% of all projects were delivered on time 2005. Over 80% was delivered after budget and time, and the rest was more or less failed projects. Only 9% of the 16% successful projects had been supplied with all the requirements customer wanted. 78% of those 16% had about 74% of the customer’s requirements and expectations.

And the size of the companies did also matter, small and big delivered different results in losses on budget. The large companies went over with a budget of about 180% while smaller companies went over by more than 220% in several projects.

That means there is a 75% chance that a project of 1000 hours will cost a small business about 2200 hours for all the requirements.
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

The numbers were changed in the CHAOS report 2013 when agile methods have reached their success by 2005. Approximately 39% of the projects was delivered in time and budget with a 100% agile methodologies such as Scrum, Lean, XP…

Why does so many project fails?
The answers are many, it is everything from how we manage projects, knowledge in organisations, how we manage our customers and attacking redundant work.

A big mistake is that we are so fixated with time. We use time to estimate the costs. This approach automatically more or less means that you agree to an up-front process that’s likely limit the customer the opportunity to request changes and you for welcoming them.  Customer thinks that estimate is almost a contract when we are done. This approach is often called Budget-Driven Estimation or Promise-Driven Estimation. And the real problem here is that customers know that estimate is just a “guess”. But they always refer to it as a promised timeframe. So in the community people want to change this word to something else though estimate is almost always converted as a promise. It would be much better to call it. “We guess it will take 1000h!” instead of telling the customer “the estimate is 1000h.” You get the point right?

And remember that estimate does not actually tell the story about the delivery time frames. The actual delivery time depends on current priorities, WIP and lead-time. But! When a customer asks “how long?” and we answer “eight weeks”, or “1200h” they think the clock has started, and expect to see results after 8 weeks or exactly 1200 hours. But the reality may be that the team will not begin work on the basis of existing PIA and priorities.

Another reason is when leaders see the team members as a developer that you can move around or replace whenever you want. We believe that a developer is equal another developer in skill and knowledge.
Two brothers created in 1980 an idea that people are not equals because they have the same title. They identified that people attack problems differently based on their experience and knowledge. And therefore created the Dreyfus model.
To rank where people exist in all there unique skills.
Source: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

It is also common to add people to an ongoing project and believe it will create greater efficiency when it’s usually do the opposite. Each new person has to be trained in collaboration, customer requirements, knowledge of the customer, etc. and it usually takes focus from an already productive team. “Nine women can’t make a baby in one month.” It’s called The Brook’s law.
Source: http://en.wikipedia.org/wiki/Brooks%27s_law

To prevent much of this we can focus out processes on the agile manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It is important to keep an open dialogue with the customer to ensure that risks are lifted up early on the surface as soon as we learn about them.
Then there is also plenty of time to reduce them. Clients / stakeholders do not like surprises as for the development team!

An estimate should never be treated as a commitment or a promise. It’s not a contract. Therefore, avoid negotiating with time to calculate the budget. Instead focus on the value for the customers and charge for them instead. Be value-oriented not time-oriented. (Part 4 in this series will show some ideas how you can get paid and sell your projects value-oriented.)

So when estimate seams so bad, do we need them? Yes and no.
You can read more about it and #NoEstimate in my Part 2. (will be published soon.)