To point or not to point?

If we start with the premise that points are an estimate of effort and not a measure of value then estimating effort (story points) for every work item type helps teams better plan the workload. When some items have effort estimates and others do not, planning becomes subjective and teams frequently struggle with meeting their forecasts.

My advice to teams is to estimate (i.e., assign points) everything and to recognize that velocity is the rate at which the team does fully tested, clean, quality work. Velocity is not something teams earn or get rewarded for – for example, saying the team earned 50 hours of effort estimate makes no sense.

My advice to managers is to not equate effort with value – one does not cause nor necessarily lead to the other. Team velocity is just a raw measure of speed, nothing else – I know that the team delivers 50 points a sprint but that doesn’t tell me if any of that work is valuable or not. If managers/stakeholders are really interested in determining the percentage of time spent on value-add work then teams can simply flag an item as value-add or not.

Of course, determining value is easier said than done because (1) value is not a constant and changes over time, (2) stories by themselves don’t always provide value but do so in concert with other stories, and (3) in many domains value added by a feature isn’t measured objectively and is hard to isolate from value added by other features delivered. Keep things simple and don’t try to guess eventual dollar value delivered/earned/saved by each story — it is an exercise in futility.

With that said, lean does provide guidance on classifying activities as value-add, non-value-add but necessary, and pure waste. Agile teams can use the same when/if they want to determine how much time they are spending on true value-add work.

---

Rules for Evaluating Activities (What is Value-Add Work?)

Value add activity:

• Transforms (changes the form, fit, or functionality of) the product or service into something that meets customer requirements
• Customer recognizes the value and is willing and able to pay for it
• Is done right the first time
• Cannot be shown to be performed more economically

Waste (2 Types)

Type 1 Waste / Non-Value Add But Necessary / Business Value Add / Organizational Value Add (OVA) :

• Not valued by the customer, but
• Valued by the business or perceived as necessary for delivering value or staying in business
  • Not valued by customer but required by organization
  • Sustains the business; facilitates value-add tasks
  • Regulatory Compliance
  • Inspection
  • Ancillary activities like HR, Payroll, etc.

Type 2 Waste / Pure Waste:

• Adds cost but not value
• Defects

The following table is my quick and dirty attempt at listing some of the software development activities and classifying them as value-add or not.

Software Development Activities

---

How do you treat velocity and value identification? Have you seen dysfunctional behavior caused by an over-emphasis on velocity and a constant pressure to increase velocity?

 

Process change shouldn’t always start with process change

A software development process is just an implementation of an idea someone had — an idea that has since taken root and flourished in people’s mind. People often identify with a process they’ve grown comfortable with and simply asking them to drop it and adopt a new one will not get you much buy-in. As a change agent, you most likely will have to deal with fear mongering, ridicule, death by delay, and stirred up confusion and doubt.

However, as John Kotter advised, “Don’t try to crush attackers with ridicule, counterattacks, or condescension, even when it seems as though people deserve it, even when a part of you really wants to do just that, and you have the skills to do so.” Instead let the attackers in and let them take pot-shots at you — that at least gives you an opportunity to have a conversation with those who aren’t yet proponents for the change.

If you want to change the current process you have to start with changing what people think about the process, what they like about it, and how they relate to it. Try to win their hearts by showing respect and keeping your responses clear, crisp, simple, and common-sensical. Show them that the proposed change is in their best interest and that you have no private ends to serve. Focus on changing what’s in their minds before attempting to tinker with the process if you want buy-in and lasting change.

 

Scrum board — a simple tool for driving improvement

Scrum boards are simple visual tools for increasing visibility and drawing attention to areas that merit further discussion. They are information radiators posted in a highly visible area that serve as the center of work discussions — how are we doing toward meeting our commitments, what risks do we need to mitigate, where do we need assistance, etc. — and drive focus and improvements.

The teams I am coaching are currently using a Scrum Board modeled on the sketch below.

Scrum Board

The top left of the board has three columns to depict progress of Product Backlog items or stories (not tasks). A Definition of Ready and a Definition of Done are used as well as a We Often Screw This Up (WOSTU) checklist. When a story is moved to the Doing column, the team members working on that story have a quick huddle to ensure they understand the goal, what they need to do to achieve that goal, the approach they’ll take, and to also remind themselves of things they often screw up. The WOSTU checklist is dynamic and changes over time — items are deleted once the team stops making the same mistakes.

A cycle time table (lower left) is used to highlight stories that took significantly longer that anticipated and merit further investigation to understand what happened, why, and what the team can learn from it. This works equally well when the team has small stories and is simply counting the stories instead of estimating them using story points.

The action items from the last retrospective are posted on the board as well to remind the team that they need to take action on those items; just talking about what could be improved doesn’t actually lead to improvement.

Finally, a handful of metrics are shown as well. The metrics should be chosen carefully to highlight areas that the team needs to improve on. For example, the teams weren’t collaborating sufficiently and were operating in a mini-waterfall model; therefore, using average story cycle time to start the conversation was helpful. The cycle times will start going down once the team begins to change their approach to a more collaborative, less throw-it-over-the-wall approach.

Scrum Boards are not static and it is expected that the team will continually adapt the Scrum Board to keep it meaningful for their own team and context. I fully expect the metrics section to change significantly over the next few sprints and the cycle time table to no longer be needed once the team becomes adept at splitting stories and focusing on story completion (and not on task completion).

What interesting information do you usually track on your Scrum Board?

 

Railing against reality

Just because you want reality to bend to your wishes, doesn’t make it so. You can fight reality all you want and you’ll lose every time. Just like you can’t make a baby in three months despite working hard (putting in overtime and working nights and weekends), having the best intentions, and having an optimistic frame of mind (thinking positive thoughts, visualizing success), similarly, you can’t deliver on unrealistic expectations that are absolutely divorced from reality. Challenges are good, ridiculous demands aren’t! Executive fiat and management by fear only gets reluctant compliance not people’s enthusiasm, innovation, and best effort.

As a Program Manager, your first order of business should be in resetting management expectations otherwise your teams will very likely become disheartened and demoralized. Help stakeholders and executives realize that there is more than thinking in binary oppositions of “all” and “none” — give-and-take on scope and depth of functionality is a good viable alternative.