This question was asked recently on a social network Scrum group. I thought that it was very relevant and also a common request from executives that desire an evaluation of ROI for agile transformations. However, it is important to consider both efficiency and the effectiveness of your agile transformation.Continue reading “AGILE MOMENT: Agile Transformations and ROI”
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.
Continue reading “AGILE MOMENT: What are themes, epics, and user stories in Scrum?”
Remote teams and Lean-Agile frameworksIn 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.
More at HBR: https://hbr.org/2014/07/managements-three-eras-a-brief-history
(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.
Continue reading “Agile Moment: How to estimate Story Points using Planning Poker”
blogagility.com 