Speed. More to the point... Velocity. It’s a way to continually discover ways to work faster and more efficiently whilst also removing wasted effort at the same time. It also has a game element to it. Each task or User Story, is assigned a number that represents the level of effort it would take to complete that task. Numbers are assign on the fibonacci numbers. Depending on the length of your sprint (most companies run 1/2 week sprints) 1 person could complete X number of points. In a 2 week sprint I was averaging ~60 points.
When the next sprint planning session occurred, a meeting where the stories are collected and assigned, you would see if you could add 5 more points this sprint. You are constantly pushing how many pts you can complete. When a team attacks this growing sprint backlog it’s known as swarming.
Ideally when you estimate stories you want them to all be 1 pt. 1 roughly equals 1 day of effort. Anything larger and you should break them down into smaller more specific stories. If I don’t I hear the voice of Mark Fischer in my head yelling…
1 point!… 1 story!…1 day!
My focus is always on what design would make the user story true. This allows for ultimate creative freedom while still adhering to feature requirements through Acceptance Criteria. User Stories go a long way to ensuring the quality and consistency of the designs are always high while also being fast.
User Story Mapping
The user story is a foundational instrument used in the agile design process. It provides a multitude of understanding around Feature Value, Prioritization, and Effort.
I follow the user story structure of
As a <role>, I want <feature> so that <reason>
User story mapping is the foundation for sharing overall understanding and setting expectations on what can realistically be achieved in a sprint. Or as Jeff Patton says,
User Story Mapping is a dead simple idea. Talk about user’s journey through your product building a simple model that tells your user’s story as you do. But it turns out this simple idea makes working with user stories in agile development a lot easier.
The user epics and stories identified from a mapping session are fed into a kanban board and run through a sprint.
Kanban boards in Trello in conjunction with the screenful.me tracking provides a large window into the design process at any given moment. I find that this allows for ultimate agility when deadlines change, and they always do.
- Use Story Mapping Backlog
- Whiteboard Backlog
- White Sprint Backlog
- Design Backlog
- Design Sprint Backlog
- Design Critique
- Activity Trail Icon [If one needed to be created]
- Zeplin Backlog [To be pushed to Dev]
- Prototype Backlog
Evaluating Progress & Effort
Using the Labels feature in Trello and a powerup built-in third party app called Screenful.me I’m able to automaticlly create realt time burndown charts, cummulative flow, and understand team velocity. I assign cards w/ the appropriate labels, which represent Epics. Those labels drive the flow chart below.
To determine effort you add a“(#)” at the beginning of the card title to assign an estimation. Screenful will understand this and update accordingly.
Screenful.me also has a “radiator” mode where it automaticlly pages through the screens. It’s great to just leave on a screen in a open area in the office to offer a view of what is being worked on and when it might be complete.
Zeplin is a product that enables me to develop very quickly by removing the tedious tasks of creating redline comps or writing CSS for style specifcs like Hex #’s for colors.
It instantly provides the frontend development team w/ up to date:
- CSS Stylesheet incl. color pallette
- Asset Images
- Object placement/spacing measurements