So far, I haven't seen any project in the wild ran by an exemplary scrum team configuration. What one does, is cross fingers and hope for a team representing all positions needed. Usually to end up with 3 testers, a horse and half a trainee.

Welcome to project Utop.ia

Day three

Technically, day 3 mostly centers around anything more than 2 sprints ago (support team) and more than 2 sprints ahead (design team). Because "linear" is for whimps. It is the hardest day, because you get confrontend with an uncomfortable truth: the outside world. The Big Imperfection.

Document highlight: User Story.

Start of day

I take pride in having introduced Zendesk in multiple projects, for that I yield appreciation from support people. It hasn't always been like that -support and developers are best pictured as cats and dogs- but these days there's a higher degree of comfort driving to a support meeting, with the prospect of enhancing that feeling of being closer to the customer side.

Outlook of this day:

Day 3 Agenda
standup 15 min max
Designs refinement Evaluate and request updates on the designs for next sprint
Support meeting Evaluate support flow and reports (do this before the testing meeting)
User stories Because your team needs it
Production zone

Designs refinement

For ease of reference, user experience design, graphics and interface design are all mashed together in the "design" definition. In reality, there is a whole array of incredible tools and topics a design team has at its disposal (I'll leave it to the Designer to elaborate on his or her toolbelt in our blog series).
That reality renders the title "Designs refinement" obsolete, of course. Rare if ever, a designs refinement meeting is spent discussing the colour of a button or the font-size of a footnote. If you do, please step back: you are micro-managing. Your design team will be packing this meeting with user validation feedback, smoke test reports or A/B insights. Fun stuff.

At the end of the day, remember that your deliverable as PO is to guard that feature changes are generally understood by the design team.

Stakeholders: PO (optional), Functional Analyst, Storyteller and Designer (leader)

Support meeting

The product support representative bears your cryptonite, handle him/her with care. Support is a great ally if you need to highlight a new feature to the sponsor - given you take the time to explain it to your support first as a solution.
Find a balance in your technical team for properly assisting the support staff, by assigning a maintenance SPOC (this can be part-time). A cycling support maintenance curfew per sprint works great to keep your team members motivated. Leave the orchestration to your Scrum Master.
The main management challenge in the support meeting is in keeping the contents high level(ish). You'll never ever have enough time to split every detail anyway. Keep for yourself the primary objective of sensing the direction public perception is heading towards, so you can either tighten or relax the maintenance impact on your team.

Every once in a while, you'll walk away from this meeting with priceless feature ideas. For that reason, avoid delegating this slot to your Analyst.

Stakeholders: Support (leader), PO, Functional Analyst, Storyteller (optional)

User stories

I'll touch the subject of my feelings about user stories later on, probably even more than once. What should be common wisdom about them: you have no product without. How more elaborative your user stories go, the better your project will run - without finding yourself micro-managing and fixing misunderstandings like a madman later down the road.
If the gods are graceful to you (let's be honest, why would they?), your team will be blessed with a storyteller. This person will become your best friend.

  • Always define the user type who's telling the story. Add acceptance requirements separately
  • Application behaviour that can't be explained in a user story, add it as technical notes
  • Wireframe the hell out of your user stories
  • It is not fair to expect blanks to be filled in by your execution team
  • Every detail you forget to mention in your user story, will be hunting you further down the road

If you don't have a Storyteller, invite the functional analyst every once in a while for user stories "refinements". Placing yourself in a situation where you have to explain a feature or interface in full, lots a details surface.

Stakeholders: PO, Storyteller (leader), Functional Analyst (optional) and Designer (optional)

User story

You probably already know this, but allow me to lay out the fundamental value of a user story. It translates the added benefit(s) of your feature ideation, from the perspective of the eventual consumer. If you have multipe types of consumers, those different perspectives should reflect. In practical terms, a user story explains a neutral wireframe in detail - possibly also limiting the outcomes your enthousiastic executement team cooks up. Without a user story, you'll never be able to get to a comprehansive scope of a feature.

Yes, I had to learn this the hard way.

Over the years, we have been using the vanilla story capturing products you'll find in any scrum team. Some are glorified text editors, better tools connect with sprint tickets. Some examples are due.

  • Confluence, the industry standard. Meh.
  • Zenhub, great product but limited for user stories.
  • Sketch Cloud, sweet but not really maintainable for long projects.

Then, during the writing process of this blog series, I stumbled upon Delibr.com. I have not yet had the ability to use this nice-looking product in the wild.

Therefore, let's give this article an interactive twist by letting you, sweet reader, feed back to me your first impressions of the tool - or your personal favourite for that matter. Contributing is easy through the series' github repo.

Tool link: Delibr.com (comment here)

Outro

If you had the human reflex to react agitated to the real world remarks of your support team, take the four following actions.

  1. Write a mail about how perfect and innovative the product actually is, and that it is not your fault that customers are mind-bendingly stupid.
  2. Print the mail and eat it dry.
  3. Write down a backlog of how the design team should think about customer usability.
  4. Send a mail to praise your support team and tell them how much they really mean to the better version of you. This one you actually send.
<< Day two - the roadmap | Scrum Team | Day four is about project managing. Watch this space