One or Two Day Tasks

Posted by mikeberry | Agile Development,Agile Executives,PMI-ACP,Product Owner,ScrumMaster | Monday 10 December 2012 10:44 pm

Recently while coaching Agile to a large client in the Salt Lake City area one of the developers on one of the teams asked me why an Agile team should decompose features into one or two day units of work.  It seems, he said, the particular unit of work he was considering could not be broken down into anything smaller than 4 days.

This is a common question for groups first exposed to Agile.   Decomposing features into one or two day tasks can be challenging at first.  Here are several reasons why it is a good practice:

1. Breaking down features and large tasks into one or two day units of work forces the Agile team member to really understand the nature of the tasks.  Ambiguity is the enemy of success and large units of work really are ambiguous.

2. Smaller units of work limit the amount of risk that a particular task can adversely impact a schedule that was estimated incorrectly.

3. Decomposing work into many one or two day tasks gives the team member a win every one or two days.   They and their teammates will njoy a sense of accomplishment more frequently, helping team morale.

4. Decomposing work in to one or two day tasks creates more transparency and precision so the team can account for completed work more accurately.  This many not be noticeable for one single work item but imagine the effect if the entire team kept work items at a non-decomposed level…too much ambiguity.

5.  Some teams I encounter hold standup meeting less frequently than daily.  This is a mistake.  Standup meetings should be held daily.  When I drill down and ask why, I typically hear that the team is reporting on the same work item the whole week.  Further questioning reveals they are not decomposing work into one or two day tasks.  When they start decomposing work into one or two day tasks then they have something new to report each day, and the standup meetings become more helpful.

Mike J. Berry, PMP, CBAP, ITIL, PMI-ACP, CSP, CSM, CSPO
John C. Maxwell Leadership Coach

Red Rock Research

Project Management Institute Announces New PMI-ACP Agile Certification Credential

Agile Certified Practitioner (PMI-ACP) will be the designation of the new PMI Agile credential.  PMI has decided to recognize the prevalence and effectiveness of Agile practices within the project management community and has constructed a tangible foundation of requirements and guidelines for establishing what constitutes an Agile framework.  Perhaps we’ll soon finally see an Agile BOK. Key dates for the PMI-ACP are as follows:(May 2011) PMI is now accepting and reviewing applications for the PMI-ACP (Sep 2011) The PMI-ACP examination will be available(Oct-Dec 2011) The first PMI-ACP certifications will be awarded to successful pilot candidates. Sign up for the PMI-ACP pilot program here:http://www.staging.pmi.org/en/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx

CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell’s Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role.This seemed to make the most sense to me, and to the others present.Mike J. Berry, PMP, CSM, CSP, ITIL

Agile Development and Requirements Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  Scrum is intentionally quiet about software requirements so that groups can use what works best for them.At Red Rock Research,  we show groups practicing Agile how they can benefit from a high-level “strategic” use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow requirements that were missed in the inception phase.This technique has proved quick and effective.Mike J. Berry, PMP, ITILv3, SCM, SCPOwww.RedRockResearch.com

Whiteboards for Everyone!

Do you like designing on whiteboards?  I do.   Colorful markers against a clean, white surface inspire all kinds of creativity and fun.

Recently David Crossett of Ready Receipts gave me a great tip.  He told me that instead of going to your local OfficeBOX superstore and paying $200 for a 4×8 whiteboard, just hit HomeDepot instead and get a $12 piece of showerboard.  It works just as good and if you need a smaller size they will cut it for you on site for no additional charge!  At that price, you can line your walls with thinking space.  Power to the Consumer–thanks David!

Mike J. Berry
www.RedRockResearch.com

Two Days with Alistair Cockburn

Posted by mikeberry | Agile Development,Most Popular,PMI-ACP,Product Owner,ScrumMaster | Saturday 11 July 2009 9:16 am

I recently attended an Agile Development Product Owner class taught by Alistair Cockburn.  The content was excellent.  He taught us about the proper perspectives an Agile Product Owner needs to successfully interact with the project sponsors, users, and the development team.Alistair Cockburn has authored several books on Agile Development, and is one of the original signers of the Agile Manifesto.I would describe Alistair’s environment as squirrely and fun.  We built user-stories out of the Rumpelstiltskin and Cinderella stories (from the original Nicht fur Kinder european versions–full of voilence and gore!)We also discussed the differences between Use Cases and User Stories.  I was happy to hear he prefers Use Cases, because so do I.All class attendees had already been through the ScrumMaster course, so as we executed sprints for our product backlog, it was interesting to see how many attendees actually sought the sponsors/users feedback during the iterations–without being reminded.Overall it was an educational and enjoyable experience.Mike J. Berrywww.RedRockResearch.com

Book Review: Integrating Agile Development in the Real World

Hooray, another book on Agile Development!

In Integrating Agile Development in the Real World, Peter Schuh explains in depth how to get your team to adopt the Agile Development Model.

Schuh covers several Agile Metholodogies including the problems to watch out for during the process.

I do have to say, this book seemed like a “whole bunch of everything” and so I didn’t feel, after reading it, that I was really any more informed about Agile Development.

I would recommend the book for a group just being introduced to the Agile Development Model.

Mike J Berry
www.RedRockResearch.com