Good Practices Gone Wrong

Photo by grahamcartergc

There's a danger in taking best practices too far and applying them at the wrong time or in the wrong situation, and it's a big challenge for leaders who are struggling to advise teams--the leaders are also learning what works and what doesn't while the teams are learning. 

As an example:

User stories are commonly used in Agile organizations, and they are often estimated in story points.  A team estimates each story in its product backlog, and knowing the team's velocity, we can predict when the work reflected in the backlog will be done.  At the beginning of a project, the team knows the least amount of information about the work itself--they will learn more as the project progresses.  There is value in estimating the product backlog before the project starts and estimating the team's velocity as an initial estimate for the project, but it's just that: the initial estimate.  It will be refined as the project progresses and the team learns more about the work.  When estimating the stories at the beginning of the project, it's common for some of them to be epic in size--in fact, that's good.  Epics can be broken down later when the team has more information, so they put a larger story point size on the epic for now as a high level estimate.  But if estimating stories is good and breaking them down into smaller stories is good, wouldn't it be good to break down all of the epics from the start and estimate those?

Not necessarily.  Are heads going to roll if the estimate is wrong?  The team has to spend more time and effort trying to break down those epics at the beginning of the project, and remember, this is when they know the least information about the work itself.  How likely is it that the stories will not change drastically by the time they get to those stories in the product backlog?  Or that the stories will be needed at all?  Epics help keep some of the details vague so the requirements can emerge later.

For every best practice, it's important to know why it is a best practice and when it is best applied.  Some of that will come through trial and error, and some of it can come from reading and talking to others outside your organization.

Allison Pollard

Allison Pollard is a coach, consultant, and trainer who brings the power of relationship systems intelligence to go beyond tasks, roles, and frameworks to create energy for change. She engages with people and teams in a down-to-earth way to build trust and listen for signals to help them learn more and improve. Allison focuses on creating alignment and connection for people to solve business problems together. Her experience includes working with teams and leaders in energy, retail, financial, real estate, and transportation industries to help improve their project/product delivery and culture. Allison currently volunteers as program director for Women in Agile’s mentorship program. Her agile community focus is championing new voices and amplifying women as mentors and sponsors for the next generation of leaders. Allison earned her bachelor’s degrees in computer science, mathematics, and English from Southern Methodist University in Dallas, TX. She is a Certified Professional Co-Active Coach (CPCC), a foodie, and proud glasses wearer. Allison is a prolific speaker at professional groups and international conferences, including Scrum Gatherings and the Agile Alliance Agile20xx conferences. Allison is co-owner of Helping Improve LLC.

http://www.allisonpollard.com
Previous
Previous

Upcoming Conference: AgileDotNet and the ALM Workshop

Next
Next

Focusing Your Energy through Lists