Shaping our development process
Why are we here?
-------------------------------------------------
What
do we want to improve?
-------------------------------------------------
How
are we going to improve?
-------------------------------------------------
Scrum process
The way we did things
- PO identifies functionalities & features
- PO (& RA) create(s) user stories
- PO (& RA) discuss this with IxD
- IxD makes design proposal
- User stories are completed with details
- PO prioritizes stories
POKER SESSION
- User stories are presented to team for estimation
- Scope of sprint is determined by estimated points
START OF SPRINT
Pain points business
- Lack of vision & decisiveness
- Lack of knowledge about actual users & usage
- No case (holistic view/concept) to present to dev. team
- Too little overview
- Product backlog is not complete or organized
- PO must specify technical details (fuzzy stories)
- Too many stories
- Too much time spent on documenting & specifying stories
- Too little time spent on actual backlog grooming & prioritization
Main issues with this approach
- dev team is involved too late within this process
- dev team is not a part of how the stories come about
- dev team is not adequately involved in thinking of solutions
- PO struggles with stories
Pain points dev. team
- Exchange between UX and developers can be improved
- Developers aren't sufficiently involved in thinking of solutions
- General lack of understanding of the users
- Stories/epics are in illogical order from dev. team's perspective
- Dev. team has (too?) little input
- Concept of 'Def of done' is too fuzzy & rigid
(difficult to squeeze it into a sprint)
Result
Development team is NOT empowered to:
- be creative, think of solutions
- create tasks
- break-down stories
- prioritize stories within sprint
- own the stories within the sprint
What to improve?
Exchange ideas across team members
Pro-activity in coming up with solutions
Decisions regarding technical solutions and UI lie with the dev. team
Owning our dev. process
Test early, involve users
Proposed
Solution
Before we get started
- Business case √
- Concept √
- Vision √
- Initial product backlog (epics) √
- Release plan √
To get this done PO needs a Project Manager, Architect, UX designer and Requirements Analist.
With this the development team gets the neccessary introduction
from Product Owner & Project Manager
...And
Know your user!
Ok great. How do we get there?
PO provides:
Who's our customer?
What pain points do they have related to our product?
How will our product solve their pain points?
What features are important?
UX for proper preparation
(works with PO/RA)
Interviews might follow (users)
Reporting might follow
UX design peaks
Proposed scrum process
- Workshop (pre-poker session) lead by UX
- prepare
- Sprint planning meeting
- estimate & plan
- START SPRINT
- go go go
Seperate the
WHAT
from the
HOW
PO provides WHAT, we provide HOW
(and don't forget to ask yourself WHY)
UX workshop
1. UX workshop
Brainstorm session *Input from the epics*
- UX 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
Result
BAMMM!!!
Solid stories!
2. Sprint planning meeting
- Stories are selected by the team from the top of the product backlog
- Keep in mind the velocity of previous sprints
- Break down stories (if needed) into tasks of 4 - 16 hours of work
- Ask PO questions if neccessary
- Think about acceptance tests (criteria)
- Estimate stories
NOTE:
Additional functionality can only be added to the sprint by the development team!
3. Start sprint
- 2 week sprints
- Developers pick up stories based on expertise and priority
- Acceptance test preparation?
- Stories move from
to do - in progress - review - test - demo - done
Definition of done
Definition of done
Stories might deliver:
- 'finished' functionality, incl. design
- all functionality, no design
- a (HTML) prototype
- javascript/html prototype
The end product at the end of the sprint may vary, depending on the story. This is neccesary since a sprint only has a fixed amount of time.
You cannot always squeeze the entire life cycle of creating a feature or functionality into ONE sprint. These are EPICS!
Dod: Team's agreement
Testing
Testing
Test as the final stage of a story before moving into done, can be user testing or some other form of test depending on the story. Therefore gathering valuable user feedback before finalizing a component or EPIC (in a future sprint).
This fits well in the Scrum methodology of continues improvement.
Epics & Definition of done
For epics there can be different criteria than for stories.
For example, performance testing can be part of delivering an epic, documentation, refactoring (decreasing technical debt) etc.
The end
Agile Development Process
By nudea
