2 months ago I switch to FeedBurner to track amount of readers of my blog. This helps me to understand if I’m living in a void 
I recommend switching your current subscription to the new one by simply tracking the feed here: http://feeds.feedburner.com/lnbogen
I apologies for the inconvenience and appreciate your time reading my stream of thoughts.
We just had our 1st Pizzability at Delver. There were 25 of us, from development, QA, HR, Project and even Marketing. We basically ate pizza and saw a few usability videos made by real users at Delver. The goal was to have fun and allow people to sit back and relax (between each bite) while watching how people are using our product. This, I hope, will help connect even further “the makers of Delver” to our users. Bon appetit!
I’m writing for about 5 years now. I’ve spent numerous hours writing about coding, architecture and management. Some people liked it although my blog is yet another stream of words in a big pile of information called “the internet”.
The amazing fact is that my top post (by far, I’m talking about ~90% of my traffic) is about Visual Studio .Net 2005 Colors!
Yes, a single post, out of hundreds, about a niche topic, got all the spotlight. Frickin’ Lovely.
So like most startups, I’ve build->didn’t measure->didn’t learn->WTF? FAILED!
This year I’m trying to drive my effort by aiming for learning first (learn –> measure –> build): starting from what I want to test (my hypothesis) then to see if/how I can actually measure it and then to build it, or write about it. I’ll share my journey as I go, hoping you’ll find it interesting.
Happy 2011 everyone!
In almost every management tool out there, there is a sophisticated roles and permissions system that allows you to pick what your developers / product manager / project manager can or cannot do with the system. “You can move a Feature to In Progress only if your Team Leader authorize it”, “Only product manager can create new Feature”, “Only Project Manager can start a new Sprint”. I see it happen sometimes also in source control tools “You can commit only after your Team Leader checked the ‘code review done’ checkbox” or “Only Team Leader can commit code”.
Again, this is an internal system being used inside the organization!
I think it’s a destructive and counterproductive approach. People will stop using tools that are making them less efficient. If I know that only my Team Leader can commit my code, I’ll probably commit once a week or once a month as I cannot sit and wait for him every 10-60 minutes that I normally commit. Same goes for management tools. People will not use the tool to its full potential, if they’ll need to send emails such “can you please create this feature for me?” or “can you please approve this feature so I could start working on it?” What’s the point? I can create tasks in my OneNote or excel file and keep moving from there.
This way, data becomes less relevant, less honest, less up to date. You should trust your people to act smart and train them to utilize tools better.
two words – backup system. Usually it’s really simply to backup your data every X hours (or minutes) and rollback if disaster occurred. Your people will get better as they’ll practice more often, get feedback from you and adjust. This will prevent disasters from happening to begin with. Backup system should allow your teammates to practice often, this is their safety net. Don’t use roles and permissions to create virtual trust or avoid personal headaches. At the end of the day, it will cost you more.
Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?
External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.
Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.
Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.
If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.
Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.
I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?
With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.
Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.
Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.
Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?
Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”
Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!
After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”. On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.
How can you translate a 3 Story Points or 3 Ideal Days to “it will be ready next Tuesday”? By using the actual time it took to perform a task or a feature, you could actually see a correlation between Story Points size (internal to the organization) to the total amount of actual work hours range (external as you can put it on the calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 actual work hours to complete. Assuming you pick a number, say 6, as the amount of “effective” work hours in a single day, such features will translate to 4-5 working days.
Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your marketing team to communicate it within their roadmap.
You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in your “Not Started” column. You also made sure that your teammates’ availability is updated as some have vacations and some got exams during the sprint.
How can you balance your tasks effort, in hours, between your teammates?
By looking at your actual work hours history, from the example above, you can see that a 3 Story Points feature translates into 23-28 hours of work. You can immediately add to all features worth 3 Story Points one task called “TBD” with 25 (average) hours and assign it to one of your teammates. That way, you can add a “TBD” task to each one of your features, simply by checking their Story Points -> actual work hours range.
Next, you slowly break these big TBD tasks, in each feature, into multiple smaller tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates. When your team is mature enough, they can break down their tasks and provide their own estimation at the beginning of the sprint.
Two flows for example:
a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.
b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.
c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.
Tracking your actual work hours is imperative as it (1) provides a way to translate internal work units to external work units and (2) enable fast estimation of large features. The key is to clearly explain how using internal estimation can help with these goals. Asking your teammates to remain open and honest about their actual effort (versus rough estimation) requires a lot of trust from their side. Don’t break it and don’t use it against them.
p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.
Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.
Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.
Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.
I’ve said it before – estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.
To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.
Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.
I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):
1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.
2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.
Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.
Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”
“In experimental science, experimenter’s bias is bias towards a result expected by the human experimenter.” – Experimenter’s bias, Wikipedia.
Almost every management tool out there attempts to provide estimation regarding when the feature / user story / version / release will be ready. Fogbugz took it to extreme with their Evidencing Based Scheduling, others such VersionOne and Mingle use pretty graphs or other visuals to achieve the same.
“Computer, when it will be done?!”
I think there is an inherent paradox with such prediction – it depends on developer’s honesty. You must ask yourself what is the developer’s incentive to fill the information as it is? why should she or he be honest? The way I see it, developers are staying in their safe zone, pricing things in high enough granularity (around 8h or more per task) and fill the actual or remained hours so they won’t look bad or good. They just want to be right. Why? So they won’t appear as too optimistic or too pessimistic to the prediction system their boss is using to plan the next few releases. It actually makes sense; the predication system caused the results to behave as expected by driving developers to “safely” play with the numbers. The actual, somehow, always equals to the estimation! How nice!
The second you’re telling your developers that their estimated and actual hours are being used directly to predict the future, don’t be surprised that it will be the future they want you to see. This is why I’m not convinced about using Actual Hours for readiness prediction or judging if a teammate is over optimistic/pessimistic.
As a team leader, you should care that your teammates will learn to estimate better, to allow themselves to be wrong, without everyone to see it on their prediction tools. They need to make mistakes and get personal feedback. People over Tools !
Why should you still use Actual Hours then?
More on it to follow…
If Sprints are not execution unit, what is the rush of moving Features to done as soon as possible during a sprint? Why should you care about it if you’re not limited by end of sprint deadline?
Other than the fact that done is fun ™ (obvious sense of accomplishment), striving for done features will push the entire team to excel. I’ll try to cover it from two angles, manager and developer.
The only difference of introducing versions to decouple execution from sprints, is that you commit to version rather than sprint. So far, no big change, you need to release on time to allow fast feedback by your customers. It’s the same “Agile attitude”, the same fuzzy feeling in your tummy.
1. Prefer small amount of WIP (Work In Progress) – we are poor with multi-tasking and we hate to get back to things we thought we already finished. If you aim to move Features to done, you can be more confident moving forward without leaving some concerns behind you.
2. Practice Growth – the more features you’re estimating, breaking (into tasks) and leading, the more you’ll improve your communication and leadership skills. Because all of the above is so hard to get right, you need to practice as much as you can to feel comfortable leading bigger features over time and later on, if desired, leading your own team. Great leaders not only know how to push features but they also can explain to others how to get better at it, to share feedback. For that, you’ll need to practice enough, to reflect enough, until you really grasp the complexity behind it.
1. Prefer small amount of WIP – you should prefer 7 features done from 9 planned rather than 15 features in progress from 20 planned. You cannot deploy half-baked features thus 15 features in progress means zero value to your customers.
2. Create predictability by making Velocity graph stable – If you want to plan your sprint faster and with more confidence, you’ll need to understand how many Story Points / Ideal Days you’re able to do each sprint. For that, you’ll want your Velocity graph to avoid spikes every sprint (example: 30 SP, 2 SP, 87 SP, 40 SP) but rather have a “stable” Velocity graph (example: 30 SP, 27 SP, 34SP, 29SP). Constant spikes mean that you won’t be able to say how many Features (by Story Points) you’re able to perform. Less confidence => more time spent on planning.
3. Create predictability by making Features Size Completion stable – again, if you want to plan your sprint faster, you’ll need to know how many big / medium / small features you’re able to pull off every sprint or every version. Try to strive for known throughput per feature size to increase confidence.
Planning Sprint, just like estimating features, might be very expensive and hard to nail down. The trick is to create solid picture that strengthen your gut feeling about what you can actually do. With this in hands, you’ll spend less time breaking everything to little pieces or worry about the quality of your plan; instead, you’ll have solid empirical history behind you to back you up. More time for you to get some tan!
