General
You can adopt the Agile mindset in many ways. Scrum, being an Agile subset, is one of them. However, focusing on Scrum only and not adopting a true End-to-End Lean-Agile process will not create a true value to the customers. Hence, in LAND we Scrum the Lean-Agile way.
In Scrum we would like to have small teams, spending little time, building small thing. That’s the reason the organization will:
- Be split into cross functional, self-organizing teams
- Split the work into User stories
- Split time into fixed length time boxes (e.g. sprints/iterations)
Scrum in LAND is built into the Lean-Agile End-to-End process (figure 1: Scrum Process). The basic unit of value (that is, MMF) is managed in the organizational backlog. Once ready and analyzed the MMF will be decomposed into user stories. User stories that are ready for development will be planned into a sprint by the team. Once all user stories are accepted the MMF is demoed and accepted. The MMF is the sprint artifact and actually the potentially shippable product increment.
So let’s see how we apply it and use the Lean-Agile workflow to create user stories for the scrum teams.
Figure 1: Scrum Process
Team Backlog
As discussed in LAND Framework, MMF is a business requirement. It serves as the basic unit of work that will be delivered to the customer. Having said that, MMF will be described from the customer point of view and will create a standalone value. As part of the Lean-Agile workflow MMFs are constantly added, sized and prioritized in the organizational backlog and streamed towards the Agile teams (e.g. LAND workflow). MMFs will be decomposed into User stories that will comprise the team backlog. As opposed to the MMF, user story will create value but not a standalone value. User story will be executed within the planned sprint. MMF may cross a sprint time box.
As discussed in LAND Framework, MMF is a business requirement. It serves as the basic unit of work that will be delivered to the customer. Having said that, MMF will be described from the customer point of view and will create a standalone value. As part of the Lean-Agile workflow MMFs are constantly added, sized and prioritized in the organizational backlog and streamed towards the Agile teams (e.g. LAND workflow).
So, the question is: how valuable user stories are created?
MMFs will be decomposed into User stories that will comprise the team backlog. User stories are also described from the customer point of view. However, as opposed to the MMF, user story will create value but not a standalone value.
Scrum team will create value by working on the team backlog. Team backlog user stories will serve MMFs that will create a true value to the customer. User story will be executed within the planned sprint. MMF may cross a sprint time box. Ready MMF may be delivered since it is a potentially shippable product increment.
Before we drill down to the story workflow let’s look at the MMF workflow. The first state of the MMF is “New”. In this state each MMF will be defined in terms of description, high level solution, Definition of Start – DoS and success criteria. Based on that, a high level sizing will be associated with the MMF. Once ready and based on prioritization, MMF will be moved to the next state – “Analysis”. In this state technical and functional design will be made. Then low level sizing will be associated with the MMF. The next step will be decomposing the MMF into user stories that will comprise the MMF as a whole. At this point the user story life-cycle begins.
User Story Workflow
The following is the states of the user stories:
New – the default state. New user story that was split from its MMF. The user story is creating a new value by definition. Each user story will be elaborated, designed and analyzed by the scrum team. At the end of the process each user story will have sizing, detailed design, DoS, DoD and success criteria.
Ready for Dev – user story that was moved to this state was designed and sized. This state indicates that the Scrum team understands the user story. It is associated with a scrum team backlog and may be planned into a sprint. Planning the user story to a sprint can take place only if the DoS was accomplished.
In Progress – user story was planned to a sprint planning and scrum team is working on the user story. User story is developed and tested. If automation is involved it will be part of the user story work. If bugs are found it will be immediately resolved and closed.
Completed – work in terms of development and tests on user story is done. The scrum team declares that user story complies with the business requirement and ready for demo.
Accepted – user story was demoed and accepted by the Product Owner/Product Manager. This means done is done.
Sprint Life-Cycle & Ceremonies
The Lean-Agile workflow will constantly stream user stories to the teams. This stream should be at a pace that creates user stories that are “Ready for Dev” of at least 1.5 to 2 sprints ahead. In such a case every team will always have enough team backlog for planning the next sprint.
Sprint Planning Meeting – The first ceremony of the sprint will be the planning. In this meeting the team is planning the next sprint. User story can be planned to a sprint only if it is in “Ready for Dev” state and DoS was achieved. The outcome of the sprint planning is the commitment of the team to the amount of work for the next sprint.
Daily Scrum Meeting – Every day the team will have a daily stand-up meeting. This is a team sync meeting in which every team member is saying what he/she did yesterday, what he/she plans to do today and if he/she has any impediments. In case of impediments, scrum master will note it and will take care of it immediately after the daily meeting.
Demo – Each user story that is in the state “Completed” will be demoed. Demos will not take place only at the end of the sprint. Scrum team will demo every time a user story is completed. Once all user stories of a specific MMF are accepted the MMF will be moved to “Completed” state and will be demoed. If MMF is accepted it means it is a “Potentially Shippable Product Increment” and ready for launch.
Retrospective Meeting – At the end of the sprint, team will retrospect the last sprint. This is a very important meeting in which the continuous improvement is being carried out.