An epic in Scrum terminology is a group of related user stories or may appear as a “big” story. Epics generally cover an entire use case or work flow for a feature related to user interaction with a system in software development. Epics are completed when all the associated stories implementing the epic are done-done. While stories may be completed and delivered independently, epics are only complete when all stories are verified done.
Remote teams and Lean-Agile frameworks
In this article I cover various strategies and methods for effectively implementing and using Agile, Scrum, Lean and Kanban (the system) for globally remote teams (virtual workforces, telecommuters). I will also attempt to debunk the myth that Scrum may not be used for remote teams. We are not going to deep dive into the “Agile” mindset, values, and principles (Agile Manifesto) or Lean thinking here. Although, they are the critical foundations for using / implementing Scrum effectively.
Over the years I have heard many people say that you can’t “do” Scrum with remote teams or some other such nonsense. I find this fascinating because I have done Scrum with remote teams for years — successfully.
We have to move away from Taylorist thinking.
Organization as machine – this imagery from our industrial past continues to cast a long shadow over the way we think about management today. It isn’t the only deeply-held and rarely examined notion that affects how organizations are run. Managers still assume that stability is the normal state of affairs and change is the unusual state (a point I particularly challenge in The End of Competitive Advantage). Organizations still emphasize exploitation of existing advantages, driving a short-term orientation that many bemoan. (Short-term thinking has been charged with no less than a chronic decline in innovation capability by Clayton Christensen who termed it “the Capitalist’s Dilemma.”) Corporations continue to focus too narrowly on shareholders, with terrible consequences – even at great companies like IBM.
(see also: Agile Moment: Equating Story Points to Time, Scrum Effort Estimation, Practical Guide Story Points Estimation, How Story Points relate to hours, Story Points vs. Task Hours, Planning Poker)
Estimating story points for user stories that implement features on the Scrum teams product roadmap / product backlog is a critical planning exercise. All Scrum teams should utilize planning methods to estimate engineering efforts for future work. There are many possible methods available to estimate effort. However, for teams that are using Agile frameworks like Scrum, a proven, highly effective method of choice is Planning Poker. The overall goal of planning poker is to establish a clear consensus on an estimate for a given scope of work or user story.
Normalization of a relative estimating technique is absolutely critical for a team to reach a high-performance state. This also directly impacts an organization’s ability to perform capacity planning and management in scaled Agile applications.
Equating Story Points to Time = Bad
I have found a common recurring issue on some of my Scrum teams over the years regarding equation of time (hours, days, weeks, months) to story points for user stories.
Read the rest of this entry »
What a really, really stupid and unconstitutional idea. That is, for the Federal Government to dictate to private companies that they publish private information.