5 Expert Tips for Agile Teams

5 Expert Tips for Agile Teams

Being Agile

Here are the 5 relevant tips for agile teams. You can use these valuable insights to create effective, self-organizing Scrum teams. These tips are in no particular order, so feel free to skim down the list and read the ones that are most suitable for you.

 

Agile Tip # 1: Discipline is the key ingredient in achieving extraordinary results. It brings stability and structure to one’s work or personal life. It takes discipline to attend scrum ceremonies, meet sprint commitments, and continually learn. As Jim Rohn rightly stated, “Discipline is the bridge between goals and accomplishment.”

 

Agile Tip # 2: In Scrum, the entire development team is responsible to ensure that sprint commitments are met. A team member who has completed his assigned tasks should look to assist other team members who need help. The team should practice empathy towards others, learn new skills, and meets their commitments.

 

Agile Tip # 3: Story points are a relative unit of measure for estimating user stories. A team’s story point estimate should include: 1) the amount of work 2) the complexity of the work 3) any risks or unknowns in doing the work 4) must-have items on your definition of done.

 

Agile Tip # 4: Split your stories into small stories. Resist the temptation to group items together to avoid the management overhead. Smaller stories flow better through the sprint. Imagine 1,000 marbles working their way down a chute rather than 100 basketballs working their way down the same chute. Smaller stories are easy to estimate and have less variability than large stories.

 

Agile Tip # 5: Define personas for your product and write persona-based user stories. A persona is a fictional character that you create based on your user research to represent different users that might use your product. Understanding the characteristics, experiences, behaviors, and needs of your personas will help you to write valuable user stories.

Also, read my agile tips on Medium.

 

Continue reading

Please follow and like us:

What is a Sprint Burndown Chart?

What is a Sprint Burndown Chart?

The Sprint Burndown or the Iteration Burndown chart is a powerful tool to communicate daily progress to the stakeholders. It tracks the completion of work for a given sprint or an iteration. The horizontal axis represents the days within a Sprint. The vertical axis represents the hours remaining to complete the committed work.

The below table shows the number of hours remaining at the end of each day within a Sprint to create a sample Sprint burndown chart. The ideal remaining hours are calculated by assuming a uniform rate of task completion each day.

 

Sprint Burndown Chart Table

The Scrum Master creates a Sprint Burndown chart using such data. The below diagram depicts a sample Sprint Burndown chart with ‘Date’ represented on the horizontal axis and ‘Remaining Effort (Hours)’ represented on the vertical axis.

Sample Sprint Burndown Chart

Learn all about Agile Scrum with my book, The Basics Of SCRUM.

 

Please follow and like us:

15 differences between Waterfall and Agile Scrum

15 differences between traditional Waterfall and Agile Scrum approach

Here's a quick comparison of the plan-driven Waterfall methodology and Agile Scrum approach:

 

Core Waterfall Features:

  • Encourages conformance to processes and tools
  • Needs comprehensive documentation
  • Restricts new ideas
  • Promotes a process-centric environment
  • Depends on contract negotiation
  • Conforms to a plan
  • Requires continuous effort to motivate the team members
  • Require a huge rework to accommodate late changes
  • Results in a high cost of change
  • Encourages a detailed project plan
  • Leaves a large possibility of a mismatch between requirements and the final product
  • Is likely to have unhappy customers
  • Supports late customer feedback
  • Requires upfront decisions
  • Does not encourage regular interaction with business sponsors

Core Scrum Features:

  • Encourages people interactions
  • Promotes working software over comprehensive documentation
  • Encourages experimentation and new ideas
  • Promotes a people-centric environment
  • Encourages customer collaboration
  • Embraces change
  • Creates high performing, self-organizing, and motivated teams
  • Adapts late changes with minimal rework
  • Has a low cost of change
  • Is based on just-in-time planning principles
  • Reduces mismatch between initial business requirements and the final product
  • Is likely to produce delighted customers
  • Encourages fast and frequent customer feedback
  • Decisions wait till the last responsible moment (LRM)
  • Promotes high collaboration with the Product Owner

Learn Agile Scrum with my complete handbook, The Basics of SCRUM.

Please follow and like us:

What is Technical Debt?

What Is Technical Debt?

Learn Agile

Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

 

Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with financial debt. Like financial debt, technical debt accumulates interest with late repayment.
In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to technical debt. He stated:

“The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”

 

Get the answers to the below questions in my management book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available exclusively at Amazon.

  • What is a Technical Debt?
  • What are the main causes of Technical Debt?
  • What are the consequences of Technical Debt?
  • How do you manage Technical Debt?
  • What are some of the practical examples of Technical Debt?
  • What are some of the practical techniques to manage Technical Debt?
Please follow and like us: