Feeling lost when discuss, with your Agile expert, here are some jargon / techniques that commonly used by Agile process.
"Prune the Product Tree" is a brainstorming exercise used to visualize the product's features and future growth. The team draws a tree where the trunk represents the core product, branches represent major features, and leaves or fruits represent smaller enhancements or ideas.
The Sailboat exercise is a collaborative Agile technique used to visualize and discuss potential risks (threats) and opportunities that might impact the project. In this exercise, the team imagines they are on a sailboat heading towards a goal (the land ahead).
A "Risk-based Spike" is an Agile practice where the team undertakes a time-boxed research activity or experiment to explore an area of uncertainty or a technical challenge.
This exercise is typically used for envisioning the successful completion of a project or a sprint. In "Remember the Future," participants imagine themselves at a point in the future where the project has been successfully completed. They then work backward to identify the steps that led to this success.
Affinity estimation is an Agile method where user stories are grouped into categories based on their relative size or complexity. In this case, the team is categorizing user stories by placing them under different columns on a whiteboard that represent different story point sizes, such as story point 1, story point 2, and so on.
Planning poker is a collaborative estimation technique where team members individually select a card representing their estimate for a user story, then reveal their estimates simultaneously.
Dot voting is a decision-making technique often used to prioritize items by allowing team members to place dots or marks on the options they prefer. It's typically used for prioritization, not for estimating the size or complexity of user stories.
Trend Analysis involves monitoring and analyzing data over time to identify patterns, trends, and anomalies. By studying the progress of the project, sprint outcomes, and other metrics over time, the team can spot trends that may indicate potential issues.
Fist of Five is a decision-making and consensus-building technique where team members rate their agreement with a proposed idea on a scale from one to five.
Yesterday's Weather is a concept that refers to using past performance as a predictor of future performance. While it can help with estimating future work based on previous sprints, it may not specifically address identifying potential issues.
Fishbone Analysis, also known as a cause-and-effect or Ishikawa diagram, fishbone analysis is useful for identifying root causes of existing issues.
Whether you are using Scrum or XP. Iteration or sprint length is the most important things to make sure the project won't late. On this article, we will discuss some tips and recommendation to make sure your sprint is better. It's a common challenge for Scrum teams to consistently hit their sprint goals. The good news is that with a few adjustments and a commitment to continuous improvement, you can significantly increase your sprint accuracy. Here's a breakdown of what you can do:
Improve Sprint Planning and Estimation:
Well-groomed uset story: Before Sprint Planning, ensure your Product Backlog is refined, prioritized, and clearly understood. User stories should be well-defined with clear acceptance criteria. Neglecting the backlog is a common reason for sprint delays. The main problem is realistic estimation always not realistic. Whether the customer said is too long, or developer said is too short! In order to solve the issues, you can implement some tricks:
Planning Poker/Story Points: Use techniques like Planning Poker or Story Points to estimate the complexity and effort of user stories. This encourages team collaboration and a shared understanding.
Focus on Relative Sizing: Instead of absolute time estimates, focus on relative sizing (e.g., this story is twice as complex as that one). Our brains are better at relative estimation, and over time, this leads to more accurate forecasts.
Account for the "How": Don't just focus on "what" needs to be done, but also "how" it will be done. Encourage the team to break down stories into smaller tasks during Sprint Planning.
Don't Overestimate Velocity: Be realistic about your team's capacity based on past performance (velocity). Don't commit to significantly more work than your historical average, especially if there are holidays or external dependencies.
Consider Unplanned Work: Reserve some capacity for unexpected issues, production support, or urgent requests. While you can't eliminate unplanned work, you can minimize its impact by making it visible and allocating time for it.
Clear Sprint Goal: Establish a clear, achievable Sprint Goal that aligns with the Product Goal. This provides a "north star" for the team, keeping everyone focused and motivated.
Timebox Sprint Planning: Keep the Sprint Planning meeting within its timebox (e.g., 1-2 hours per sprint week for a two-week sprint). The Scrum Master should facilitate to ensure discussions are focused and productive.
Collaborate and Commit: Ensure the Development Team, Product Owner, and Scrum Master are all actively involved in Sprint Planning and committed to the sprint goal and backlog. The team should select items that are feasible for the sprint duration and their capacity.
Enhance During-Sprint Execution:
Consistency: Hold the Daily Scrum at the same time and place every day if you handle more than one project it should happen once a week
Focus: Keep discussions concise and relevant to the sprint goal. Focus on what was accomplished yesterday, what will be done today, and any impediments.
Identify Impediments Early: Encourage team members to raise impediments as soon as they arise. The Scrum Master should actively work to remove these blockers.
Maintain Focus: Minimize distractions and interruptions during the sprint. Protect the team from external requests that could derail their focus on the sprint goal.
Visibility of Progress: Use tools like a burn-down chart to visually track sprint progress like kanban. This helps identify issues early and allows for timely adjustments.
Avoid Scope Creep: Resist the temptation to add new work to the sprint once it has started, unless absolutely necessary and with the team's explicit agreement. This protects the sprint goal and avoids delays.
Quality and Technical Debt: Don't neglect quality assurance and technical debt. Budget time for bug fixes and non-feature work to prevent future delays and maintain product health.
Learn and Adapt (Retrospective is Key!):
Effective Sprint Retrospectives: This is perhaps the most crucial ceremony for improving sprint accuracy. we should execute every sprint closing OR at least once month.
Safe Environment: Create a safe and open environment where team members feel comfortable sharing honest feedback about what went well, what didn't, and why. Do one on one if necessary
Identify Root Causes: Go beyond surface-level issues to identify the root causes of delays or missed commitments. customer or developer problem we should classify
Actionable Improvements: The retrospective should result in concrete, actionable improvement items that the team commits to implementing in the next sprint.
Follow Up: Ensure that the agreed-upon improvements are actually implemented and their effectiveness is reviewed in subsequent retrospectives.
Analyze Past Sprints (Velocity): Regularly analyze your team's velocity (the amount of work completed in previous sprints). This provides valuable data for more accurate future planning. However, remember that velocity is a forecast, not a guarantee, and it can fluctuate due to various factors (e.g., team changes, holidays, unexpected issues).
Continuous Improvement Mindset: Embrace the Agile principle of continuous improvement. Regularly inspect and adapt your processes based on what you learn from each sprint.
Common Reasons for Sprint Delays to Address:
Poorly defined user stories/requirements: Leads to rework and misunderstandings. TRY to regularly contact the client
Over-commitment: Taking on too much work in a sprint. TRY to calibrate the first commitment
Unexpected complexity: Tasks proving more difficult than estimated. TRY to negotiate
External dependencies: Waiting on other teams or stakeholders. TRY to schedule regularly
Unplanned work/interruptions: Production issues, urgent requests, etc. TRY to allocate spare time to do this.
Lack of focus: Team members being pulled in different directions. TRY to limit parallel project.
Poor communication: Misunderstandings within the team or with stakeholders. TRY to do daily communication
Inadequate testing: Bugs found late in the sprint or after release. TRY to do QA process
Technical debt: Accumulated "quick fixes" that slow down development. TRY to improve codes quality by using AI
Team churn: Changes in team members impacting capacity and knowledge. TRY to not include new team member in the middle of project
By systematically addressing these points and fostering a culture of transparency, collaboration, and continuous learning, your team can significantly improve its sprint accuracy and consistently deliver valuable increments of work.
Agile project management means implementing project management in agile ways. so the next question is what are the differences between agile and conventional project management. On this article, we will discuss five keys different in Agile Project management
- Agile project management means iterative and incremental. Agile project management (APM) works based on the timebox, iterative and incremental. While the conventional process works in sequential
- Agile project management follows the agile manifesto. it means more communication, more focus on people, and more adapt with changes.
- Agile project management adapt to changes, there is no fix scope. The scope always change as long as the people, product, and funding is supported
- Agile project management teams work more dynamic job description rather than role based model. team team like scrum master, product owner, and development team with collective ownership
- Agile project management provides new ways of documentation and tools. The term like user story, sprints events, and provides new way to estimate and to communicate
Programming is a challenging task. You need to focus, to solve a problem, and to create a solution for problem. There are so many ways to do programming. In Agile environment, programming can be done through three ways. Solo programming, Pair Programming, and Mob Programming. This article will discuss when you choose one compare to the others.
Solo (all in one)
This is just like a song from Katty Perry featuring Clean Bandit. Solo! Solo means you do by yourself. You did plan, do, codes, and test activities. The solo great when
Project is simple and less complexity.
Less external dependencies and stakeholders.
Limited user experience
Benefits of solo programming are:
Faster in development
Codes are understandable.
Easy to manage.
Challenge in solo programming is:
Limited design principles applied during the development process.
Exhausted and bored
Undocumented codes
You can learn more here The Personal Software Process (PSP) (cmu.edu)
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Pair (~2 developers in same role)
Pair is a couple way to do programming activity. Pair programming is great when.
Pair is available with different skills and knowledge.
Pair is great when face-to-face communication.
Pair is great when we have same role in a team.
Benefits of pair programming are:
Well-design product two head is better than one.
Transfer knowledge happens.
Shared ownership of the codes. The pair knows the codes.
Challenge in pair programming is:
Slow down the productivity.
Hard to implement in distributed environments (e.g., different time zones)
Suitability of pair person.
You can learn more about pair programming here On Pair Programming (martinfowler.com)
Mob (> 2 members in different role)
Mob is more than two peoples work together. Mob is great when.
Having members with different skillset
Having a good workspace to work together.
Having a jell team with good communication model.
Benefits of mob programming
Project understandability is the highest among the team members.
Validation and verification happen between members.
Near real time feedback model to shape the well-designed project
Challenge in mob programming
Specific infrastructure is needed.
The communication between members should be fluid between team members.
Limited productivity when the others work while the others only see the process.
You can learn mob programming here Mob Programming Basics – Mob Programming
So which one you prefer as your programming style? Put a comment please.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
User manual is still needed. However, it should as simple as possible. The real question is, what the content of user manual that can be as simple as possible and provide simplicity guide for the user. This article will guide it for you. If you are Scrum or XP user, this agile user manual is for you. This is the improvement of my previous post Creating Agile User Manual (ridilabs.net)
What you Put in Your Manual
Technically not everything on the DevOps work item. You can put the essential information such as
Product vision, mission, and success criteria
Product version and history
Product actor. Who will use the product?
Product feature. List of features
Product user story
Product guide how to use the user story.
User story limitation and rules
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";