List of the Best Agile Practices
People who work in accordance with Agile principles can explain why they have chosen this methodology in their own ways. Everyone can determine obligatory and “sacred” practices in this methodology; someone can point to non-binding or unloved practices.
However, today Agile is one of the most popular methodologies in project management and its practices are appreciated by many developers and managers all over the world. What are the key Agile practices that make the methodology famous and beloved?
To anticipate a possible reaction: the list below is definitely incomplete. Perhaps it may seem controversial. Here are only the best practices project managers need to be familiar with.
The list of the best Agile practices
Agile teams select the amount of work possible to be done based on the available hour’s team. Agile iterative development means that the team itself may decide what it is able to do based on their capabilities and experience from the previous iteration.
Customer collaboration is a crucial point in Agile methodology. According to the approach, Agile team should provide all the info needed to the clients and inform them of the progress. Constant communication should be also a part of internal teamwork.
Big project’s tasks often need to be cut into the pieces. In this case, a product manager/ product owner and team members determine how much work is needed to complete each task. Then they need to prioritize all the issues based on customer’s business needs.
Usually, a product backlog includes the following items: product features, possible, bugs, knowledge acquisition and technical work.
All the items in the backlog are ordered depending on their business value. The higher the specific item is, the sooner developers will work on it. The top-located items will be more detailed and clearer in comparison with the lower items. All of them should be clear and easy to understand for non-technical stakeholders.
Managing product backlog includes arranging product backlog refinement sessions.
In Agile we describe the functionality of communication with customers and then describe the product’s position in a very specific way (remember the easy template “I want to … because …”?). A user story in Agile project management means a unit of work that should be completed in one Sprint.
User stories include description, acceptance criteria, and estimation of the time. When they are too complex, product managers brake them up into smaller pieces.
The Agile methodology involves different roles with different names. If generalize, the common Agile roles include the following group:
- Team Lead, Project Lea, and Scrum Master
- Team members
- Product Owner for Scrum and On-site customer for XP
Agile teams may also have extended members for technical or domain expertise.
Value stream analysis
Here the methodology introduces us to two principles. The first one is about defining the product based on user stories, which are based on analysis of the business. The second one is about defining dependencies between the business and technical functionality.
The importance of timeboxing
Timeboxing is also used for individuals use to address personal tasks in a smaller time frame.
Sprints last according to the specified timeframes. It is usually from two weeks to one month. Scrum meetings are stiff and they usually last about 15 minutes.
It often involves having deliverables and deadlines.
This event is a daily short morning meeting, arranged usually by a product manager or a product owner. It lasts 10-15 minutes and requires the presence of the Scrum master and the whole team.
The meeting has three main issues to discuss:
- to remember what was done yesterday
- to define the current goals
- to reveal any obstacles
Sprint demo meetings
This kind of meeting is arranged when you are ready with the functionality and it’s time to explain how it works to the client. It is important because the customers can confirm that they accept all features and that they were made in accordance with their expectations and requirements.
This is about the meeting of the final iterative development. It is recommended to all team members to attend this meeting. Customers may also participate.
Here possibilities of improving the processes, the quality of work, tools used, etc. are discussed.
The code is up to date because of continuous integration. All code was created which will be verified before it is connected with the old code. It simplifies the testing of new user stories.
Any session starts with writing programming adaptive tests and they are preceded by unit tests. Then the code specific to the user stories is written.
This chart demonstrates whether all the things really go according to the calendar of programming and the total plan. It reflects the work schedule and timing. Burndown charts will also show the number of user stories per unit of time, below or above your plan.
It rather important to get quick information about the functionality that is not working as planned.
Any regression test is run automatically before starting work. It ensures that all code changes are acceptable.
Requirement prioritization is used in Agile product management for determining which specific product requirements should be included in a certain release.
Product managers also prioritize the requirements to minimize risks during development – the most important requirements are implemented first. In this case, experienced product and project managers use well-known prioritization methods and techniques.
In Agile, user stories are implemented in pairs (involving a primary and secondary developer). The expert works with the novice. It means that there are one owner of the user story and the other programmer who provides timely support.
Code reviews are also carried out in pairs. It is proved that logically applied programming in pairs yields better results than two developers working separately.
A product release is a set of new features or a product launch that is aimed to provide value to customers. Releases planning helps teams to launch new great products.
What is a well-prepared release? It is not only about the providing access to new functionality. It is a final date when your team is able to deliver a new customer experience and support interaction associated with it.
All concerned parties should be aware of when they can expect new functionality. The calendar of releases must always give a clear message about it. It will help to correct the code timely if needed.
As it was mentioned above, this list can include many other practices related to requirements, design, construction, testing, and process and organization issues.
If you think that the key part of the list should include some particular practices that are missed here, please let us know in the comments.