These are work methodologies that allow adaptation to the circumstances of the projects and reduce the documentation processes, they are generally used in projects that do not have a defined scope with certainty, which causes them to be very prone to change, because in these methodologies deliveries of functional products in a short time (2 to 4 weeks) allow the process of changes and correction of errors to be fast and not have a very high cost for the project in general.
Modern Agile is far broader than the Agile Manifesto for Software Development. Modern Agile is a concept that is taking many different areas into account, not just software development. It can even be applied in organizations without software development.
To clarify how Modern Agile came to be here’s a snippet from the website: Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
Modern Agile methods are defined by four guiding principles:
Some of the best known and used agile methodologies in the industry are:
It is an agile methodology that is based on constant communication and review of the tasks performed (sprints), for each sprint the planning, quality assurance, development, quality inspection and feedback processes are carried out, this reduces the cost in the correction of errors because a sprint is terminated until the client accepts all the acceptance criteria . The base values of this methodology are innovation, flexibility, competitiveness and productivity.
It consists of the elaboration of a table or diagram in which three columns of tasks are reflected; pending, in process and finished. This table should be available to all team members, thus avoiding the repetition of tasks or the possibility of forgetting any of them. Therefore, it helps to improve the productivity and efficiency of the work team. Among its objectives is to improve work planning, improve performance, define continuous delivery times.
It is a methodology based on a set of rules and good practices for software development in highly changing environments with imprecise requirements, therefore, it is focused on continuous feedback between the development team and the client. XP is based on simplicity and aims at customer satisfaction.
A user story is a lightweight method for quickly capturing the who, what and why of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each.
The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that customers don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.
- Definition of Done: The story is generally “done” when the user can complete the outlined task.
- Outline subtasks or tasks: Decide which specific steps need to be completed and who is responsible for each of them.
- User: For Whom? If there are multiple end users, consider making multiple stories.
- Ordered Steps: Write a story for each step in a larger process.
- Listen to feedback: Talk to your users and capture the problem or need in their words.
- Time: Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
- As manager, I want to be able to understand my colleagues progress, so I can better report our success and failures.
- As customer , I want shopping cart feature so that I can easily purchase items online.
- As manager, I want to generate a report so that I can understand which departments need more resources.
Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint. Is an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items.
This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.
Product Owner: Identifies the candidate product backlog items and their relative priorities, as well as proposes a sprint goal.
Team Members: Determine how many of the product backlog items they forecast they will be able to complete and determine how they will deliver those product backlog items.
Scrum Master: Typically facilitates sprint planning in order to ensure that the discussion is effective and that there is agreement to the sprint goal and that the appropriate product backlog items are included in the sprint backlog.
- Discuss any new information that may impact the plan.
- Confirm any currently known issues and concerns and record as appropriate.
- Review the definition of Done and make any appropriate updates based on technology, skill, or team member changes since the last sprint.
- Present proposed product backlog items to consider for the sprint backlog.
- Determine the needs, sign up for work, and estimate the work owned.
- Product Owner answers clarifying questions and elaborates acceptance criteria.
- Confirm any new issues and concerns raised during meeting and record.
- Confirm any assumptions or dependencies discovered during planning and record.
- ScrumMaster calls for a group consensus on the plan.
- Team and Product Owner point out if this is the best plan they can make given what they know right now.
- Get back to work.
Backlog grooming, also referred to as backlog refinement or story time, is a recurring event for agile product development teams. The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning. Regular backlog grooming sessions also help ensure the right stories are prioritized.
- Product Owner: Is tasked with facilitating backlog refinement sessions. However, that doesn’t mean they are solely responsible for holding backlog grooming sessions.
- Team Members: These events are meant to be collaborative. That means the entire cross-functional team should be represented at refinement sessions.
- QA representatives: You need the combined expertise of the various functions on your team to effectively flesh out your user stories.
- Removing user stories that no longer appear relevant.
- Creating new user stories in response to newly discovered needs.
- Re-assessing the relative priority of stories.
- Assigning estimates to stories which have yet to receive one correcting estimates in light of newly discovered information.
- Splitting user stories which are high priority.
- Get back to work.
A daily stand-up meeting is an opportunity for the project team to discuss a project’s progress at a high level. These meetings last approximately 15 minutes and allow each contributor to report on their accomplishments since the last stand-up meeting.
True to its name, all participants in stand-ups usually remain standing to keep the meetings short and on-topic. However, virtual stand-ups are also possible.
In Agile project management, daily stand-up meetings are essential. These meetings allow project members to share critical information, openly discuss issues, and hold themselves and each other accountable.
- Daily stand-ups allow team members to work collaboratively toward project goals.
- Daily stand-up meetings are important for keeping Agile teams focused and on-task while providing quick, project-level updates to the rest of the team.
- The Agile methodology is all about versatility and flexibility, it’s important to make tweaks and improvements to your meetings to fit your team’s needs.
- Your daily stand-up should inform and draw out issues so that you can keep your project on track and get ahead of issues before they pop up.
Is a meeting held after a product ships to discuss what happened during the product development and release process, with the goal of improving things in the future based on those learnings and conversations.
An agile retrospective forces the entire team to pause and reflect on what transpired and discuss what worked and what didn’t during a particular project.
Retrospectives can be held more frequently, including for minor releases, each sprint or even at daily or weekly standups.
The sprint demo is invaluable for keeping stakeholders up to speed with the progress of product development. It allows them to feedback and discuss with the Product Owner and Scrum team any possible amendments to the Product Backlog which would help to maximize value.
The sprint demo shouldn’t take up too much of a Scrum team’s time. Ensuring that the sprint review meeting is an informal affair where questions, feedback and discussion are welcome – allows for prep time to be kept to a minimum.
- Tell a story: This is one of the most important factors for a great demo, and also the most overlooked. Given the structured nature of Agile stories and epics, it’s easy to fall into the trap of simply enumerating the work that you’ve done. This isn’t necessarily bad, but it’s unlikely to excite non-technical stakeholders.
- Let developers brag: Whenever possible, it’s great to allow developers to present their own work, which helps to build confidence, morale, and a sense of ownership. A good compromise can be to have one organizing speaker with a different “guest” developer showing off their work each week.
- Set expectations: Setting expectations and providing context are critical for a successful demo.
- Action items: List all completed stories in your agenda, weed out any stories that shouldn’t be demoed, organize the remaining stories roughly into scenarios or topics, decide whether to have developers help give parts of the demo and always set expectations and give context throughout the demo.