Sunday, August 21, 2011

Release Planning with Business Stakeholders

 I just posted in the Yahoo group Agile Business the following (slightly edited):

***
The past 3 (business) days I worked with a team in Atlanta to do release planning with the Business Stakeholders.

And the business stakeholders were external customers.

I was extremely impressed with the results.  I strongly recommend it.

Situation:
* 15 people (6 pigs, 3 consultants, 6 external customers).  Plus me.
* Very beginning (well, not quite, but no prior product backlog at all....'they' had had some discussions and some ideas about a vision).  The PO had some ideas about releases, and some ideas about how his company could see a business opportunity vis-a-vis the competition.
* One day spent 'level setting' with all: what is scrum and what is agile estimating and planning. I called this a one-day 'Scrum' course.  Some were brand new to lean-agile-scrum. Some were very experienced with Scrum.

Results:
* 3 releases scoped out
* Pretty good Prod Bklog for Release 1.  Less good for R2, R3 -- but still fairly decent.
* Each story had BVP and SP (BV points and Story Points). Well, in R1.
* Vision: done
* Some good discussion about Infrastructure, Architecture and Design (as I call it). But not finalized.
* Work 'ordered', eg, including risks, dependencies and other stuff.
* Good discussions around notions of CBA (cost-benefit analysis) and Pareto (doing 20 to get 80). Everyone seemed to 'get it' in a useful way.

* Good acceptance of adaptive planning ideas (that this was the first pass, and it would evolve)

* Everyone felt fairly happy but 'brain dead' after 3 days.

Some Learnings:
* I will share if you are interested.

Questions or thoughts?
Happy to share more (up to a point) if you are interested.


***
It is a rough post. But I am excited about this and wanted to state it here also.  Comments welcome.


4 comments:

Raju Chellappa said...

Good Post. Can you share more details of how exactly you structured the discussions? That is did you use some methodology? Also any presentation that you did to explain SCRUM and Agile with the crowd that you can share?

Artem Marchenko said...

All the examples from real life are interesting. It would be cool to know how everything went later.

As for right now, what did the team do when lots of spiking about significantly new and potentially impossible functionality was needed (e.g. it would be real cool to make everything run 10x faster, but can we improve our framework that much?)

Any buffers planned for injecting some features to the release if spike proves it is possible? Or were all the features desired clearly possible and easily estimatable?

Joe Little said...

Hi Artem,

Well, I would characterize it as a very successful 3 days. But not as successful as your questions imply that it might be.

For example, the pigs did not individually estimate all the stories in the first release. Many of them (half?) were estimates using the 'speedy' method, ie, once we had a range of SP from 1 to about 30 as I recall, then we let the pigs just place stories based on where they felt they were on that continuum. They argued about only a few.

In my opinion this is ok to get something roughly shaped up, but not 'good enough' for release planning.

We spent a lot of time in Day 1 identifying user stories for 3 releases. And then later, a fair amount of time trying to see if some of the user stories in Releases should be moved up or down (Pareto-like, you might say), eg, between releases.

Also remember that the real release planning was done in the 2 day workshop portion. (The first day was just 'course'.)

And they did not have time, in the 2 day workshop portion, to really do anything like what you talked about. (Take an hour or two and identify spikes to do.) We talked about some work being 'risky' in terms of its estimate, and that was follow-up work. But not done then.

There was a set of 'infrastructure' work that they identified. Not in detail. And they left a buffer in the first release for some of that infrastructure work to be done. I would not say the buffer was estimated with much precision...but it seemed reasonable to me.

There was discussion of spikes, but I don't recall any specific spike stories being identified. Yet.

Finally, in this case, I think they did not feel on the bleeding edge of technology much at all. There are data quality issues in this industry, but in general the industry is not on the bleeding edge of technology. So, while some details of implementation might turn out to be easier or harder (than anticipated), I don't think they felt anything might turn out to be impossible to do. So, this to me raises the question: could the software company have gotten the customers to be yet more aggressive in their use of technology?

Still, while with 20-20 hindsight we might have reached higher in our aspirations, I think what was achieved compared to what had been achieved before...it still was a great 3 days.

Yes, I will try to talk later about what will happen later. A lot of it to me is the willingness of the customers to participate in the agile process and find commonality in their needs. It looks very much like they will. The question is how much.

Regards,
Joe

Joe Little said...

Hi Raju,

Yes, I will share how I structured the workshop portion. I did what I usually do for release planning (I thought I had blogged already on that, but I have not yet. I will.) And we added a few things that enabled the consultants to contribute more.

And I will explain this more. Later.

Yes, I used a slide deck to do the course portion. For a variety of reasons, I do not make that deck public. But I do make it available to those who take one of my courses, the deck used in that course.

Still, I have in this blog talked already about many of the ideas I discuss in the course. So, in that way, much of it is public.

Thanks for your interest.
Joe