Organisational Flows
Agile Scrum operates around the concept of a “story”. Groups of stories are known as Epics. Epics are “big stories” or “umbrella stories” and typically aligned to scope. The story is the individual piece of work that delivers the scope. The concept of a “Theme” is also used in Agile Scrum. Themes can be used to group stories across epics, projects and programs. Themes don’t always align directly to epics, but they can do.
To elaborate a requirement (or tender), the Product Owner and perhaps representatives of scrum team build up the set of epics and stories. The epic could be thought of as a generalisation of the need, whilst the story is a specific piece. The format used for describing epics and stories varies between implementations, but typically each contains a narrative that represents the need and associated value for that piece. Additionally, epics and stories typically have confirmation statements. These confirmation statements are encapsulated in the Goal, Conditions of Satisfactions and perhaps Acceptance Criteria. The Goal is a single statement or truth that needs be realised. Conditions of Satisfaction are statements that must be true for the story to be deemed “done” when the team finishes working on it. Acceptance Criteria are more technical in nature and depict specific scenarios that must be achievable for the story to be deemed “done”.
To estimate a requirement (or tender), the Product Owner conducts sessions with the entire scrum team (or teams) to estimate the relative size of each story. Estimation is done via a method known as ‘Planning Poker’, where everyone in the team provides their estimate at the same time to avoid junior members of the team blindly following senior members. Multiple rounds are often held to obtain consensus. The relative size is typically recorded as “story points” using a Fibonacci sequence . These points provide the basis for the release planning. Release planning is the process by which the scrum master and the Product Owner maps out the delivery schedule. Release planning uses historic data regarding the number of story points completed by the team over time. The schedule that results is only a guide and must be revisited every time stories are added or completed. Agile Scrum operates on the principle of fixed time and fixed resources, with scope being the main variable. Therefore, release planning is more about projecting how much will be achieved by the team over given period, rather than when the team will be finished everything.
The boundaries on activities within the Agile Scrum approach are defined by Definitions of Done (DoD). The DoD contains principles and rules that will guide the team in how they estimate, prepare and complete stories, sprints and projects. Typically, teams will have a DoD for the project, a separate DoD for the sprints and a separate DoD for the story. Story DoDs can be thought of as shared statements of confirmation, i.e. truths that all stories must meet in order for each story to be considered “Done”.
To deliver a requirement (or tender), the scrum team take groups of stories and work on them over set periods of time (also known as Sprints). Sprints are typically between 1 and 4 weeks in duration. The duration must be agreed upfront by the team, suit the type of work and be aligned to the story sizing. The groups of stories in a sprint are generally taken on in the order of priority set by the Product Owner. During the sprint the Product Owner cannot change or influence the work being done by the sprint team. At the conclusion of each sprint the team presents the finished stories to the Product Owner for sign-off. The Product Owner will generally only sign-off stories that satisfy the Conditions of Satisfaction, Acceptance Criteria and Definitions of Done.
A crucial component of any agile approach is on-going learning. Sprints are designed to be small so that changes in priority can be accommodated but also so that process challenges and improvements can be addressed immediately. Agile Scrum uses the concept of the Retrospectives at the conclusion of every sprint. The retrospective is a structured and open forum conducted by the team to surface and then action areas for improvement and also to give praise for successes.
No comments:
Post a Comment