Category: Scrum

What's the ideal Sprint length

November 20, 2009 by Jack Milunsky

Introduction

I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly.

As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.

The Context

A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.

Switching stories mid sprint

October 24, 2009 by Jack Milunsky

Introduction

I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.

Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it's worth blogging about this particular situation once more.

The response I received was "You're not serious you're going to ignore the PO" and "You can't be a slave to the process"

In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:

State of Agile

October 9, 2009 by Jack Milunsky

Introduction

Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

Measuring velocity is not enough to determine team productivity

June 20, 2009 by Jack Milunsky

Introduction

Another interesting question was brought up in a LinkedIn discussion thread this week: "Is velocity the right approach to measure productivity of team members working in Scrum. If not, then how can productivity of team members be measured in Scrum?" Here are my thought on this topic.

The purpose of velocity

Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal – sustainable throughput. Velocity in my opinion, is not a metric for determining productivity. Productivity or team efficiency is difficult to measure and probably best left for another blog post.

Scrum falls short in at least one area in my opinion

June 5, 2009 by Jack Milunsky

Many of us have come to love Scrum, including me. Scrum has been a huge success overall and has turned many a development team around and for the better. Yet in my opinion, I think Scrum falls short in at least one area.

Concept to Cash

Firstly, It's commonly accepted that Scrum does not consider the whole life-cycle. i.e. it's a great framework for helping development teams tame the development life cycle but it does not tackle all areas from "concept to cash". Lean and Lean with Kanban certainly appears to be an alternative to Scrum or at least coupled with Scrum to provide and all round concept to cash highly effective framework for producing software products.

Our Story Board is Better Than Yours

May 25, 2009 by Janusz Marcin Gorycki

I have decided to take a break from my usual bi-weekly musings about high-level, theoretical subjects and devote this post to something more concrete. I would like to show you how our story board that we use for sprints looks like. This may be of interest to both newbies and advanced users. The former will have a chance to see how this sort of a thing looks in practice, the latter will be able to compare with their own story boards and share their opinions, praise or criticize (in a constructive manner of course).

The subject is also interesting because it gives insight into the evolution of our team, its dynamics, its priorities – I think it is safe to say that our story board is a reflection of who we are and what sort of a project we are working on.

Let me start with a disclaimer: this story board is not “by the book” – it is not exactly the type of board that is described in Scrum handbooks. It started that way. But over time it has evolved, mutated, adjusted itself to fit our needs. “By the book” solutions are good in theory only, day-to-day reality requires you to be more inventive than what “the rules” require.

When is the story too big?

May 14, 2009 by Peter Stevens

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.

When should you advise your team not to accept a story because it is too big?

3 Warning Signs

Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:

1. Past performance indicates you won’t get it done
2. The story is large compared to the team capacity for the sprint
3. The demo is complicated and / or demos many sub components.

Coping with change on Scrum projects (Part III)

May 1, 2009 by Jack Milunsky

Introduction

This could be the last in this series unless of course I get new inspiration or I get specific requests to cover additional roles. This week I'll take a look at how the lives of QA testers and Developers are expected to change on Agile (scrum) projects. Frankly, I think that for these two disciplines, life gets much better i.e. developers and testers benefit most transitioning to Agile from Waterfall.

Developers

Developers love to do things right. Nine times out of ten, they'll argue against taking short cuts. They hate the fact that they are forced to deploy code that they know deep down is less than stellar. As with anything in life, making the shift to agile swings the pendulum over to the complete opposite side. So for the one out of ten code hackers out there - beware. The biggest change a developer can expect from a shift to agile is that engineering discipline or rigor is set to the max.

10 Contracts for your next Agile Software Project

April 29, 2009 by Peter Stevens

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project?

Coping with change on Scrum projects (part II)

April 24, 2009 by Jack Milunsky

Introduction

Interestingly, this week saw a spate of posts dealing with this very topic - although much more specific. In particular, one of the questions raised was "How does a manager add value on a Scrum team?" This segues nicely into this weeks post in which I intended to cover how the management roles (general managers and project managers) are expected to change in an Agile environment.