Lean Agile Development 2.0
Reasons for this presentation
Learn from the past and improve the way we do things.
Have a solid development process in place which the team fully supports and owns and is adjusted to their needs.
A process which integrates UX and facilitates incremental development and early testing.
What we will discuss
Our process will consist of the following steps:
- Preparation phase
- Guesstimate
- UX workshop
- Sprint planning
- Sprint!
Scrum process
Scrum roles
There are more roles than just PO, Scrum Master and Team members!
Role of Product Owner
- Is market focused
- Develops long-term and short-term product strategy & road map
- Helps position the product against competition
- Thinks about long-term viability of the product
- Does NOT make "knee jerk"* decisions
- Is responsible for the preparation phase and the product backlog
* an immediate unthinking emotional reaction produced by an event or statement to which the reacting person is highly sensitive
Preparation
There's more to it than just user stories & sprinting
Preparation is everything
Preparation phase
- Business case √
- Concept √
- Vision √
- Initial product backlog (stories) √
- Release plan √
Must have in order to start the project!
MUST HAVE * MUST HAVE * MUST HAVE
Who's prepping
Product owner
with help from
Project Manager, Architect, UX Designer & Requirements Analist
he puts this together.
Role of Architect/Sr Developer
in the preparation phase
- Safe guard that other systems/applications, external partners and consumers of the application's data are not forgotten
- Advise the PO in prioritizing the issues by assessing the possible technical solutions and effort required
Vision
Preparation leads to insight
PO provides:
Who's our customer?
What pain points do they have related to our product?
How will our product solve their pain points?
Know your user
Personas
Identify the user's pain points
What is a pain point?
- Something the user finds really annoying
- Something the user can do but the path to doing it is extremely inefficient
- Something the user repeatedly does incorrectly and then has to fix
- Something it seems the user should be able to do but cannot (because of a bug or because there is no way to do it)
Added value of prepping
To ensure there is:
a business case, solid vision, you know where you're heading
and you know your user!
And most importantly:
to be able to communicate this to the development team to give them direction, a sense of purpose and so that they understand.
This is the only way to reach a certain level of quality and create a foundation for writing stories.
Output =
Stories
= WHAT
Title
Definition of Done for stories
Stories have different acceptance criteria than tasks.
Before a story will be considered 'Done' all this criteria must be met. Some of this criteria can be separate tasks in a sprint.
Stories
Are specified by Product Owner
with the assistance of the Requirements Analist
and with the help of UX Designer (if the needs of the user have to be researched/assessed)
"As an [user type] I want to [do some action]
so that [business value]"
Stories are not tasks!
They're bigger and state WHAT needs to be built, not HOW.Stories (what) vs Tasks (how)
Guesstimate stories
Development team will 'guesstimate' (roughly estimate) the stories at the top of the backlog to give PO a rough idea and so that he can prioritize these.
We can guesstimate based on T-shirt sizes!
S | M | L | XL
Business value vs effort
After the guesstimate PO is enabled to weigh value vs effort and base prioritization of the stories in the backlog on the relation between these two factors. Thus a guesstimate can help the PO in prioritizing the stories.
UX workshop
Pick up stories
Role of UX Designer
The UX designer(s) become facilitators and stewards of the design.
Their
goal is to communicate a vision for the product by building a shared
understanding across the team. This shared understanding comes about
through regular conversations and discussions around early design ideas.
UX workshop
- UX Designer explains user & his problem
- Present possible solution/sketch to get started
- Each team member thinks of possible solution (sketch)
- Every one gets few minutes to present his solution
- Come to best solution by choosing/merging ideas
- Team asks PO questions if necessary
Sketch out idea
Collaborate
Output =
Solution
= HOWBreak down into tasks
Think of acceptance criteria when doing this!
Keep with the Definition of Done (of stories).
Sprint planning
- Estimate the tasks in hours
- Pull tasks into the sprint
- Break them down further (if needed) into tasks of 2 - 16 hours
Determining the goals of the sprint is a process of negotiation
between the product owner and the team.
Sprint!
Sprint
- 2 week sprints
- Developers pick up tasks based on expertise and priority
- Testers prepare acceptance tests
- Tasks move from
to do - in progress - review - test - demo - done
NOTE:
Additional functionality can only be added to the sprint by the development team!
Workflow
Scrum master's role
Team needs a dedicated Scrum Master
Tasks & definition of done
PO sets out DoD of stories - DoD of tasks are set by team
Testing
Test, before moving a task into done, can be user testing or some other form of test depending on the task. Therefore gathering valuable user feedback before finalizing a component or story (in a future sprint).
Deliverables of a sprint
At the end of the sprint you might deliver:
- 'finished' functionality, incl. design
- all functionality, no design
- a (HTML) prototype
- JavaScript/html prototype
Think in tasks!
Deliverables of a sprint
The end product at the end of the sprint may vary, depending on
the tasks. This is necessary since a sprint only has a fixed (and short) amount of
time.
Remember: Scrum is a process, it doesn't dictate WHAT is done.
You cannot always squeeze the entire life cycle of creating a feature or functionality into ONE sprint. Therefore don't expect to finish an entire story in one sprint, focus on completing tasks instead!
Done
Our Development Process 2.0
By nudea
