Get Agile: Scrum for UX, Design & Development

Don’t plan to work on the product right up until the last minute before the demo. Unexpected things always seem to happen on the last day: Adobe Fireworks keeps crashing; Google Chrome isn’t installed on the demo computer. Anticipate these things by making sure you have a working, demo-ready product, well before the review starts. In other words, have a “Code Freeze” and stick to it. Spend the last hour cleaning the place up and getting everything ready for the stakeholder’s arrival

A good practice is to come up with three different versions, or “flavors”, of a story solution: solutions that may differ in complexity. We call them “light”, “medium”, and “deluxe”. The light version is the most minimal solution you can think of. As simple as using the CMS for example, which requires no programming at all. It may not be the best or most elegant solution, but it’s better than nothing. The deluxe version is the ideal solution: it’s the most usable for the end user and/or the most technically sustainable. The medium version, you might have guessed, sits somewhere in between.

Ask each team member to put a random object (like a poker card or pen) on the last story they think they will be able to complete in this sprint (according to the Definition of Done). Everyone does this at the same time, so as not to influence each other. It will then become clear how many stories the team thinks it will be able to achieve in the sprint.
♦ Ask the PO if this is acceptable. If not, challenge the team to think of ways to do more in the sprint. This is a very important step. Are there any redundant tasks? Can we think of smarter solutions? Can we swap large stories for smaller stories?
♦ Ask the team to commit to the sprint backlog.

Determining backlog for beginner teams or sprint 1
In the first sprint, the complete estimation process is quite a lot of work, so stay focused.
♦ Sprint planning starts with a discussion of the stories that the PO wants the team to tackle in the sprint. Discuss each story briefly. This part is often referred to in Scrum literature as “Sprint Planning I”. If the PO is well prepared, each user story will have already been written on an index card. And there may already be some designs, which should be printed out.
♦ For each story, write down tasks on post-its and paste them on or next to the user story cards.
♦ Ask the whole team to arrange the stories in order of complexity on a large surface: largest story on the left, smallest on the right. Do this in silence for 3 minutes or so.
♦ Take the second smallest story and give it 2 points.
♦ Use Planning Poker to have the team estimate the other stories in relation to the 2-point story.
♦ Rearrange the story cards, this time in order of the PO’s priority (business value).

Eventually, epics should be broken down into smaller stories, but they can be roughly estimated prior to that. In fact, it’s a good idea. It gives the PO an idea of their size and complexity, and triggers discussion between the PO and team about what is really wanted. However, as helpful as this estimation of an epic may be, the PO should remember that the team can’t commit to this estimation. Commitment doesn’t happen until the sprint.

The project manager has mainly a supporting role. If this person is not the Scrum Master, he or she assists the Scrum Master with matters such as team changes, sprint planning, and financial issues.

MVP implies that the product must work extremely well and meet the customer’s main goals, and, as such, be a finished entity. But don’t go straight for the most complete, cool product. After the initial release, you will have enough time to make improvements

Contrary to popular belief, the entire Scrum team does not have to be working on the project on all of the Scrum days. Often, development requires more workdays than design. You may decide to have four or five days of development, and three or four days of design. Do try to have the team seated together, even on days when designers may be working on other projects.

In Agile, future quality is more important than past decisions. Trust is more important than documentation. Freedom in exchange for commitment.

Any Sprint result should be a product or product part that’s ready-to-deploy —with no fake copy, no blocking issues, no black boxes or white spaces.