Agile Project Management Tools in practice
Headmind Partners continuously promotes its consultants in training and getting certification in Agile, such as Professional Scrum Product Owner (PSPO I). If you already had the opportunity to experience it, you should be familiar with some Agile concepts that might still feel a bit theoretical, especially if you are not used to work in the IT sector yet.
How are these concepts used in practice?
Most of the tools available on the market – such as JIRA or Azure DevOps (old TFS) – will propose you to manage your projects in Agile through the creation and lifecycle of different items: Epic, Feature, User Story, Task, Impediment …
In this article, we will have a look at the usual elements of a User Story as it is one of the most basic and important items describing a piece of functionality of your product to be delivered by your team and representing value by itself for the end-user.
After creation, a User Story will usually gather the following elements:
You have to be aware that you will rarely (if ever) deliver a project only by yourself and limited to your own use. Therefor these tools will offer you a way to communicate to all your stakeholders by keeping them informed about the progress on your projects and taking appropriate actions depending on your planning, dependencies and issues. However, to make this communication efficient, you will have a key role by maintaining the good quality of the data in these tools.
- Item Title should be clear enough so any stakeholder will directly understand what is to be delivered just by looking at the title. Ambiguous titles will only bring confusion and raise unnecessary questions.
- Tags defined by your organization will provide stakeholders with specific information (e.g. Is the next milestones in danger? ) or inform about actions to be taken ( e.g. Are IT controls applicable?)
- Assignee: It’s important to indicate correctly the owner of the User Story (i.e. responsible for updating its status) as you may need to contact this person to have more information … A common mistake is to have unassigned User Stories which may lead stakeholders to conclude that nobody is working on them in the ongoing planned sprint, for instance.
- Assigned Team: As for the Assignee, a User Story that is not assigned to the correct team may result in stakeholders loosing time by contacting the wrong team (to get information) or misunderstanding the scope of the User Story (as every team is normally working on a specific product).
- Iteration: A User Story planned in a wrong sprint may have a huge impact on the planning of the entire project. It may be a mandatory piece to start testing with clients that cannot be postponed, for instance.
- State & State Reason: it’s also important to have the correct state (New, Ongoing, Done) of all the User Stories in order to have clear status of the full picture. Stakeholders may have to take important decisions – such as rescheduling a release in production – based only on the state of some User Stories. Of course, the reason of a specific state may also be relevant in some case.
- Links are usually a subpage where you can define the Parent, Child(ren) and Dependency(ies) of your User Story. For instance, a dependency that would not have been identified between two User Stories may result in a delayed delivery as the first User Story cannot be used without the second one.
- Attachments may be documents providing clarification on the solution to be implemented. The may also be mandatory documents to validate the testing or approve the release of the User Story in production, for instance. In such case, any missing mandatory documents will systematically create issues in the lifecycle process of the User Story.
- Description should define ‘Who – What – Why’ of the need. If the description of the User Story is not clear enough, it may lead in wrong understanding of what needs to be implemented.
- Acceptance Criteria are a set of predefined requirements that must be met to mark a user story as completed. As for the Description, Acceptance Criteria that are wrongly defined may result in development of poor quality.
- Story Points/Estimated Efforts should be always coherent with the velocity (i.e. nb of Story Points delivered in one sprint) and help to maximize the predictability (i.e. Percentage of planned Story Points that have been actually delivered in the sprint) of the team. In some cases, they may also be used to size the global efforts of a project. Wrong estimates may result in budget overrun.
As a conclusion, you can see clearly with the above list that delayed delivery, poor quality or misleading stakeholders may easily occur just because of some elements that would be wrongly managed in Agile project management tools. If you ever have the opportunity to take a key role in an Agile organization such as Product Owner, it needs to be 100% clear for you that many people and actions may depend on how will ensure the data quality of the items in your scope.
https://university.atlassian.com/student/collection/850385/path/1083901