Danube - blog entry - Comments

I am hoping I can join in on

rome appartments — Wed, 2 Jul 2008 05:33:17 -0500

I am hoping I can join in on this game soon.

Great Article

pparker — Wed, 25 Jun 2008 08:06:46 -0500

The recent teams I've worked with get wrapped up in hours estimated for each Sprint, over analysis can cause team paralysis. Management wants to ensure each person on the team is at full capacity during a Sprint and want the estimates to match hours available. Unfortunately, it is a reality in most organization that projects are capitalized and the hours spent working on task need to be captured for business reasons. Therefore, they look at the initial estimates as gospel (i.e. in the Waterfall tradition). Until a development organization can show true benefits from loosely coupling task hours and capacity will this problem be resolved.

P.Parker

shippable vs. sellable

MichaelJames — Mon, 23 Jun 2008 18:00:50 -0500

To help people get what DrDan's saying here, I sometimes explain "potentially shippable" does not mean "potentially sellable." We might have "Hello World!" fully tested, refactored, and documented. But not many would buy it until we get more stories done.

"Potentially shippable" is mostly a technical distinction, while "potentially sellable" is a Product Owner call.

--mj

Comment on "potentially shippable"

Dan Rawsthorne — Mon, 23 Jun 2008 14:37:37 -0500

MJ states, above, that the team's job is to produce an increment of potentially shippable product every sprint. This is the party line, and I believe it, but I get lots of questions about what potentially shippable product means. It does not mean shippable, as that is way too high a bar. We develop stories (PBIs), that combine to produce shippable features - it makes no sense for a story to be shippable by itself, IMHO.

What we mean is, if the feature is shippable (from a functionality perspective), then each of the stories that makes up the feature is shippable (from a quality perspective). So, stories that are done have the quality they need to be able to ship them, which means that the feature they are part of can be shipped as soon as it is functional - no waiting time to add in the quality! The way I refer to this is that the stories are demonstrably done every sprint.

Same concept, different words.

Dan ;-)

dan@danube.com
Dan Rawsthorne, PhD, CST
Transformation Coach
http://www.danube.com

opqtrew

pwe — Mon, 23 Jun 2008 04:35:15 -0500

online games

poqtrje

esdgdfg — Mon, 23 Jun 2008 04:34:43 -0500

free online war games

sdgikyky

dsadsf — Mon, 23 Jun 2008 04:34:03 -0500

play war games

sdhhfgh

cvbvcxfdsg — Mon, 23 Jun 2008 04:33:27 -0500

free online games

Brian

MichaelJames — Thu, 19 Jun 2008 17:26:32 -0500

Brian,

I can see why you might want to do that, especially for a longer Sprint, or in cases the work does fit the more predictable pattern. Another cool idea might be to show "ghost lines" from the team's previous Sprints.

ScrumWorks Pro is released several times per year. Feature requests can be submitted to Victor Szalvay (ScrumWorks Product Owner) here:
http://forums.danube.com/viewforum.php?f=4

--mj

Trendline

BrianBurdick — Wed, 18 Jun 2008 01:10:06 -0500

HI Michael,

I understand your points regarding anchoring, the non-linear nature of sprint progress, etc. I Still like to see the trendline for some kind of visual reference. I find myseful imagining the trend line anyway. I don't get to stressed out if I am way above it in the first half of the sprint. I would kindly ask that you at least make it an option - even if by default it is off. Also - it seems with the data that you have from previous sprints in each organization, that you could create an ideal curve based on the curves of previously completed sprints for the organization - a kind of best fit average burndown curve. This might more accurately reflect progress. It seems the data is already there in the product burndown - it just needs to be used per sprint as a curve.

Unicorns and Software, The Human Element

Jim Schiel — Mon, 16 Jun 2008 17:34:42 -0500

As for Sprint lengths, I agree. There are times, like near the end of a project, that a shorter length can be beneficial. However, modifying more than is absolutely necessary is simply not advisable.

As for the tool protecting itself from unexpected use -- I feel very strongly here that a tool could never and should almost never act as a guardian against what it's users want to do. Why? Because a tool can never be certain that it's aware of all of the realistic effective alternatives. Should it warn against potentially ill-advised uses? Sure, but only if the user can turn those warnings off. Although, even there you should pick what you need to warn about. Apple has had a field day laughing about Vista's warning. Obviously, there's a limit. In my experience, it's usually not the tool that causes the problems, but the lack of procedural discipline that is a root cause.

As for that "bad feeling" you get when people want to track actuals, I used to get those too. I still do, in fact, but now I know why. It comes down to this, if we had machines performing Sprint Backlog tasks, we could eliminate almost all of the circumstantial causes that effect machine performance. In other words, other than temperature, humidity, parts maintenance, and the quality of the inputs, machines will perform the same and similar tasks within a very slim variance in elapsed time. When you replace the machine with the human factor, you introduce uncounted variables that affect the completion of the task. Skill level, task focus, how much sleep the developer got the night before, etc.

All of these variables affect the performance of the developer and not necessarily within a very slim variance. In my personal experience, there are times when I can knock out complex code or detailed documentation in my first attempt and there are times when my first attempt makes me look like I've never seen a computer before.

Therefore, comparing one task to another similar task might seem simple on the surface, but once you throw in the entirety of the human element, it's a whole new ball game.

I much prefer using Sprint Retrospectives to find out what is working and not working for the team. It doesn't seem scientific, but it is effective and routine retrospectives (once after every Sprint) helps to "tune" the environment, recognizing that what works one month may not work the next because of the humans on the team.

Jim

Ajayaram, I certainly

Jim Schiel — Mon, 16 Jun 2008 17:08:33 -0500

Ajayaram, I certainly wouldn't argue that there's never a benefit of tracking actuals in certain instances. As a Six Sigma Green Belt, I could definitely see the possibility for opportunitites in understanding where the team is spending too much time.

And don't get me wrong -- I'm not arguing against tasks in the Sprint Backlog -- that would be quite an obscure approach indeed. No, instead I'm simply suggesting that I've never, in 24 years, seen much opportunity in tracking actuals. Usually the circumstances from one "similar" task to another is so varied that it is quite difficult to isolate enough of the circumstantial effects to actually compare tasks.

Indeed, if improving team performance is a goal, may I recommend Sprint Retrospectives where the team is asked how and if they feel they are wasting or losing time on specific types of tasks of even if they are routinely forgetting types of tasks that they should remember during Sprint Planning or adding tasks during Sprint Planning that they really don't need. While I understand the possible use of task actuals in this scenario, I believe you'll find a in-depth retrospective much more efficient.

However you choose to proceed, good luck! I hope you get the same satisfaction from using Scrum as I've gotten over the past years.

Jim

Sprint length and time tracking

Jon Torresdal — Mon, 16 Jun 2008 16:18:22 -0500

Regarding sprint lengths I agree with you, but I've also seen and experienced situations where having one sprint shorter/longer than usual makes sense. Specifically with teams working with legacy code that needs a stabilizing sprint at the end where the normal sprint length is say three weeks and they need a two week sprint for stabilization. Some might not call this a sprint at all and don't use any tool to monitor there progress and just start finding/fixing bugs.

Regarding a tool like ScrumWorks supporting varying sprint lengths I think that could be ok, though bearing in mind that the user might misuse the tool as you mentioned in your post. But is it the vendors job to put a safety harness around the tool so that the users should not misuse it? Should the tool warn you if you create a sprint with different length than before, and argue why this is bad?

Your point about time tracking I fully support. I also get a bad feeling when this comes up and I can't really clearly explain why. In general I usually state that keeping track of time spent and keeping track of progress are two different things, and only one of them fits my view of Scrum. I therefore also recommend using two different tools, one for time tracking and one for "Scrum".

Very insightful article, you

Canada Drugs — Fri, 13 Jun 2008 07:47:57 -0500

Very insightful article, you are right, analyzing the situation reduces the risk for bad decisions. When it comes to medical world things change a little bit, many decisions have a certain degree of uncertainty, the responsibility is huge because we are dealing with people's lives and such situations can become very pressing.

Simply display links between PBIs

Casper — Thu, 12 Jun 2008 06:15:32 -0500

One solution to this common problem could be to somehow figure out a way to visualize any "links" between PBIs representing actual "business value", and their respective "children" representing technical dept.

Although scrum enforces as few dependencies as possible between PBIs, it still might be necessary to add it.

"Business value" PBIs with little or no dept-children might be prioritized over PBIs with many dept-children, but isn't that exactly what our main goal was? To visualize how much technical dept will be involved (and how much extra work needs to be done) on each business value PBI.

My point of view is, that techical dept doesn't become a problem until you need to interact with it, change it or expand it. So if PO decides never to prioritize PBIs with much technical dept to it, that's fine. The tests will never be written, but since no changes will affect the legacy code, it really doesn't matter that much.

Just my five cents :-)