Group items tagged

Managing little stories forces us to keep better track of how they fit together. Product owners are often asked to break down stories to a level where a single story becomes meaningless. To keep track of what’s meaningful to them and other stakeholders, they often need to keep track of bigger items such as the features of the product and how many stories contribute to building up that feature.

The result of these herniated time-box activities is a cycle that’s actually 3-4 times longer than our time-box. To get work done, we’ll use a time-box to elaborate stories, one to develop them, another to more thoroughly test them, and if there are bugs, possibly another to fix them.

During an ideal Agile time-box we’ll have frequent discussions between developers, testers, and those on a product owner team — like business analysts, user experience people, and business people. We’ll do this to understand what we need to build and describe what we’ll do to validate the story was really done. When time-boxes are short, there’s less time for this conversation. It’s common to move many of the conversations to detail the story and describe acceptance to the time-box before so we can be ready to really get moving with development when the time-box starts.

It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs� which often get piped into a subsequent time-box.

Anyone who’s attended an Agile planning meeting knows they can often last about an hour longer than you can stand it

As time-boxes shrink those on the product owner team and testers find themselves in a constant mode of getting ready for a next time-box and evaluating past time-boxes

work long hours, attend lots of meetings, and seem to have less time to be available to help developers with the current time-box. Since their focus is on a future or past time-box, questions about this time-box seem like interruptions. Collaboration decreases and tensions increase. Their work load is heavy, bumpy, not smooth or even.

Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)

“Kan” means visual, and “ban” means card or board.

Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team.

In Kanban development: time-boxed development is out stories are larger and fewer estimation is optional or out completely velocity is replaced by cycle time

Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development? Don’t get hung up on process. Remember, agile development isn’t a process.

You might have a column where business analysts spend time tracking down technical details that developers need to understand to write code.

These columns aren’t set. You should discuss with your team the phases that stories go through to be completed. Some organization may use columns for writing documentation, or preparing customer service people to support the feature in production.

The top is used for stories currently in progress in that phase. The bottom is the buffer. When work for that phase of the story is completed, it moves from “in progress” to the “buffer” where it’ll wait to be pulled into the next phase.

When we set limits for work in progress, we’ll set a total number for the process step that includes both “in process” and the “finished buffer” for that process step.

Stories must be minimal marketable features

To be marketable the feature needs to be large enough to be useful — probably larger than the teeny stories that take a couple days to build and seem to be best practice in Agile development today. A MMF may take weeks to build. But the important thing isn’t how long it takes to build, but that it be understandable and valuable to those who’ll receive it. To identify a MMF some folks ask the question “Would I announce it in my company’s product blog?” If it’s too tiny to mention, then it’s not a MMF.

To be lean, we’ll limit the number of stories we allow onto the board. A common formula is to add up all the members of the team in all roles and divide by two. All roles includes developers, analysts, user interfaced designers, testers, deployment people — anyone immediately responsible for getting features to market. For example, if team members total 20, we might limit the number of MMF-style stories on the board to 10.

Today developers have finished a story, and s they walk to the Kanban board to move it out of development, they notice their single buffer slot is full — and the “testing in progress” column is filled to its limit. What now? The developers talk to the testers. “We’re really struggling to keep up here. It’ll be till tomorrow morning before we can get some of these stories moved out.” “Hmm�” says a developer “Can we help test?” “Of course you can!” says the tester. “With your help we can get these cleared out by the end of the day.“ The tester grins “I just don’t want you validating a story you implemented.”

For the limits of the story process steps, the limit is often half the number of people that can perform the work for that phase of development. For instance if you have 6 developers, you might limit the development in progress column to 3. Now, this will force developers to work together on stories. I do find in practice that this may not work out for all teams — so I often see limits that equal the number of developers (or those that can perform the process step) or often 1.5 * the number of people in a role. Of course if you do this, it’ll raise the overall work in progress — and as you might expect, items will take longer to finish.

When a column in a Kanban board is full, we know that group is at capacity. We also know that if this keeps happening that that process step is likely where a bottleneck is.

If you’ve ever waited in line for the Pirates of the Caribbean in Disneyland you might remember signs along the way that say “Your wait time from here is 30 minutes” — something like that. Now you can post your own wait times on your Kanban board. At the bottom of your story queue post the average cycle time with wait time. It’ll say something like “Your wait time for a story here is approximately 18 days.” At the top of the queue post the average working cycle time. It might say “your wait time from here is 14 days.”

When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.

But, since there’s no development time-box in Kanban development, we’ll measure story-by-story how long they took to complete — the “cycle time” of the story.

Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”

If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.

If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.

Evaluation cycles, not development time-boxes

The only difference is the cycles aren’t used to plan and commit to stories any longer.

The daily standup or daily scrum meeting occurs as normal, but now it occurs in front of the Kanban board. Instead of the regular meeting ritual of checking in with each person to find out what they worked on yesterday and will work on today, the discussion revolves around the Kanban board and what will likely move on and off the board today, where “traffic” seems the heaviest, and what we could do to clear bottlenecks.

Reflect every few weeks

Lean practices help teams increase throughput. They don’t make developers type faster, rather they draw attention to bottlenecks that slow things down, help you see them and respond to them quicker. Using a Kanban board lets you easily visualize work in progress across different roles and lets you see when someone is taking on too much work simultaneously.

Demonstrate every few weeks

A task board as it’s commonly used in an agile approach can give you the visualization too. But, widening the task board to separate testing from development from acceptance or other process steps helps me better visualize where things are clogging up — helps me better diagnose problems. And, setting hard limits for process steps and respecting them really makes me deal with the problem in a way that dropping a pile of stories into a sprint or iteration didn’t. But, maybe it’s just me who’s lazy and avoids dealing with tough problems. I’m sure you’d never run into a situation where you and your team let lots of finished development work pile up waiting to be tested.

There’s no one as zealous as the newly converted There’s a lot of folks pretty excited about Kanban out there. I am too. Sometimes that zeal takes the form of telling people practicing common agile time-boxed development that they’re wrong. But, I guess I’m crusty enough to know that there’s lots of right ways to succeed and anyone who believes they’ve found the best ways is likely wrong. Don’t let those voicing opinions strongly for, or against, Kanban approaches stop you for digging in deeper and understanding the ideas behind it.

We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.

We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

ultimate user (mobile device user) is fairly far removed from the major technologies

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

Embedded Systems Example - Symbian Software Limited

Clearly, the development of a mobile phone operating system is a highly technical endeavor

mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV

the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

All our POs come from engineering teams and are senior engineers with product or customer experience.

one PO to two team mapping typically, rarely 3 teams, sometimes 1

IS/IT Examples

role/title of the Business Systems Analyst

is often a reasonably good fit for the Product Owner role.

In the larger IT shop, I have also seen the role filled by Project Managers

In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business

Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests

magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.

The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.

Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.

here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.

Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.

As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.