Embracing Agile: An organizational adoption
In the article Agile Story Types, I discussed the different types of stories in the Agile m4ethodology. As mentioned then, they are the foundation of the methodology and this note will discuss how the various users will use them to create a continuous work effort. Agile is a process for defining continuous work effort and it requires adoption by the entire organization to achieve a high performing SDLC. It is much more than something only developers use. In an Agile SDLC,not every Sprint will have a releasable product (I will discuss release planning strategies later). Additionally, the Agile methodology provides a strategy for incorporating CI/CD into the development and deployment process.
Epics
The highest level stakeholders will be creating Epics, then grooming them into features and Product Backlog Items. Ideally, this is the job of the Product Owner, who would then coordinate with the Scrum Master to produce User Stories. Epics are normally used to describe a business need. Something new in this post is the concept of a Product Backlog Item. A PBI (Product Backlog Item) can be a feature or high level user story that contains the requirement(s) to produce a minimum viable product.
Product Backlog Item
A single Epic will consist of many features and PBI. The Product Backlog should not be confused with the Sprint Backlog, since these are two entirely different things. Another new item in this post is the concept of a “minimum viable product”, which represents the minimum set of features or work that is necessary to deliver a set of changes to the customers. Determining the MVP is going to be used in the release planning process. A PBI is a type of user story that is defined by the stakeholders and then gets refined by the Product Owner and the Scrum Master into Sprint User Stories.
Difference between a PBI and a Sprint User Story
A PBI is used by the business stakeholders and it contains the business requirements that need to be met as a result of the work effort. A Sprint User Story is used by the development team and, while it also describes a set of work, it will also contain the requirements by the IT department to meet the standards that have been set. An IT department will have either an Architect or senior developer that leads others when it comes to adhering to policies, and ensuring a well designed set of work. As you can see, the IT department has their own set of requirements that must be met, which is why we break a PBI up into Sprint User Stories and add the necessary IT requirements. Additionally, the business doesn't need to become Technology experts, and they can focus on the stories as they relate to the end user.
Sprint Tasks
The purpose of the Sprint Task is to assign work to an individual, establish guidelines for time management and evenly distribute work. Repetitive tasks are identified easily and then automated or replaced with a reusable component.
As you can see, the adoption of the Agile methodology is something that the entire organization must embrace. Agile is a powerful tool for creating an SDLC that enables everyone in the organization to have input, while continuously delivering work even if the requirements change.