Advanced Topics In Scrum » Good Scrum

Scrum Out of the Nutshell – Video

admin — Thu, 11 Jun 2009 18:59:08 +0000

This is my first attempt at making a Livestream cast with Video. The talk is on Scrum and is really a primer or refresh of what Scrum is. There will be several more videos coming that will start to make up a knowledge track that you can follow through.

I hope you enjoy. Please leave a comment on your experience.

Look for more videos coming soon from a wide audience of practitioners, coaches and trainers.

Epic

admin — Wed, 03 Jun 2009 04:47:52 +0000

Another major topic for discussion here is the Epic, which many think is just a “large story.” However, I like to define epic as an item that can’t be committed to by the team. This could be for a variety of reasons, most of which are captured in the acronym CURB:

Complex	The item might be too complex to be understood well enough to be committed to.
Unknown	Maybe nobody on the team knows enough about the story to even make a guess whether it can be committed to.
Risky	There are too many unknowns; it is too risky to commit to the story without further investigation or a mitigation strategy.
Big	It could just be too big to do in one sprint, even though it is well understood.

In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.

Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.

Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.

Some examples of epics are:

• “We want the system to be able to manage the pilots’ schedules”;

• “We’re going to need to train all our users on this new release”;

• “As a , I want to ”; or

• “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.

Minimum Marketable/Releasable/Demonstrable Feature

admin — Mon, 20 Apr 2009 05:05:19 +0000

The following terms have been pulled from literature and/or cast here for further exploration of a core concept.

In all of the following the biggest risk is not building the right product.

Incremental Funding Approach (IFA)
- Should we spend any more money?
Minimum Marketable Features (MMF)
- How much and what product do we need to win?
Minimum Releasable Features (MRF)
- What can we release so that we can satisfy demand now and get more feedback?
Minimum Demonstrable Feature (MDF)
- How can we show case the product and thereby get valuable feedback early & often?

These are all methods to be validation centric. The constant challege in complex product development is to build the right product.

More to follow this thought is still baking

Scrum In A Nutshell

Doug Shimp — Wed, 08 Apr 2009 22:26:38 +0000

No wasted words (that’s what you get when your friend is a mathematician), this is a 1st draft of an excerp from our book written by Dan. It offers a very quick, powerfully concise summary of Scrum.

Download Scrum In A Nutshell

excerpt… “While the Stakeholders are the most important people for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is held accountable by them for the success of the Team. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.”

How much is the PO truely seprate from the team?
Is there a single wringlable neck?
Is the team / PO a symbiotic ecosystem with a centralized model for detemining direction? thoughts?

This is free for you to consume. It is our hope that you will provide comments and feedback. Those that do can register on our community site and provide constructive comments. They will be acknowledged. We will use your comments to evolve the explanation of thought here or clarify ideas. As you read, hold on to your shoes because each sentence is loaded with deep layer focused meaning and if you skip around reading this will hurt your understanding.

done/done/done/done

dan — Mon, 29 Dec 2008 15:11:08 +0000

A few years (about 6-7, I think) I introduced the team “done/done/done”
into agility in order to describe what “done” meant in an agile setting.
It is now pretty established the “done” is a HUGE concept in scrum, but
at the time we were just figuring it out. My thinking at the time was
that a Story was “done” when it was “Done/Done/Done”, where the three
“dones” meant (coded/verified/validated). That is:

* Coded – it works on the developer’s box
* Verified – Unit tested and they work on Integration box
* Validated – accepted by ProductOwner as being what was needed

Later on a fourth “Done” was added for “Production Ready”, which meant:

* Production Ready – all additional stuff was there, like
documentation, training for users, etc

Now, I still like the four “dones”, but have a slightly different focus.
Since Stories are now well-defined bits of work, with well-defined
definitions of done, there is no longer the subjective third “done” for
them. The Product Owner no longer gets to decide if it is what is
needed, the story is defined to be done once the acceptance criteria are
verified. So there is not a hierarchy of things we do:

* Stories get “Done/Done”
* Features get “Done/Done/Done”, and we don’t know how many stories
this will take
* Products get “Done/Done/Done/Done”, and we don’t know which
features this will take, or how many stories it will take

This new way of looking at things shows us what is really going on.
Within the team’s work there is only tactical agility, where the team is
being agile in figuring out how to meet its story’s acceptance criteria.
There is low-level strategic agility where the PO is deciding which
stories to deliver for each feature in order to provide the value (for
that feature) that is needed. And there is high-level agility where the
PO is deciding what is the “releasable feature set” necessary to
actually be able to put this thing into production. Three different
levels of agility, three different sets of stakeholders, three different
levels of abstraction and questions to ask.

Dan Rawsthorne
dan@danube.com