Daily Scrum for Freelancers

Daily Scrum for freelancers and other teams of one

Thrill & Create does user-centered digital product design for the amusement industry. In other words, we design websites, microsites, apps, and any other digital products with a view toward making these products easy to use and enjoyable for park guests, business partners, and any other prospective buyers in the amusement industry.

Although we work hard not only on design but also on running our business, we also endeavor to work as smart as we can. We regularly see how we can improve our process.

My background in work processes

As a former software engineer for large, mid-sized, and small companies, I was able to ship products successfully in each setting using widely varying processes.

The large company, a multinational corporation which had a team in the hundreds for our project, used a traditional waterfall process. The requirements team handed off their work to the logical design team, which handed theirs to the physical design team. The waterfall proceeded to the development teams and to the test teams before it was turned over to the customer. Meetings and signoffs abounded, and going back to a previous step was largely impossible. To speed up the schedule, the project team was split in half, with each half of the team working on a separate release. While with this company, I started becoming very interested in software development processes and read my first several books on agile.

The mid-sized company used a team in at least 3 states and a spiral development process. They, likewise, had separate people working on each step: requirements, design, development, quality assurance, and integration testing. But the teams staggered their work so that each group could stay one step ahead of the next group.

The small companies used geographically distributed teams and agile processes. I was generally responsible for working on individual features and bug fixes and carrying them through to completion through design, development, initial testing, and supporting quality assurance engineers or systems engineers as they tested my work. Our teams would have daily stand-up meetings and twice-weekly calls with team members in other locations. In each stand-up meeting, members would answer three questions:

  1. What did you work on yesterday? (or on the most recent work day)
  2. What are you working on today?
  3. Are you blocked, or stuck, on anything? (Are you waiting for anything to happen which is keeping you from being able to finish your tasks?)

The advantages of agile

First published in 2001, the Agile Manifesto lists 4 core tenets:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

While agile teams still value the items on the right, they value the items on the left more. Agile processes allow companies – particularly smaller companies – to respond quickly when their clients want something changed. They also tend to minimize, but not eliminate, paperwork.

1. You spend more time doing design, development, or testing.

I was surprised at how little time I spent writing code at software development companies that used a waterfall process. Other team members and I spent many weeks between development iterations writing comprehensive documentation and waiting for other groups in the project team to hand off their deliverables to us. In the agile shops, I wrote code nearly every day.

Designers in an agile project can spend more time designing. Developers can spend more time developing. And testers can spend more time testing. They all become better at their crafts faster. No more sitting around for weeks with nothing to do while you wait for another group to get their work done. There is generally a lot less waste in agile processes.

What that means for you: Agile gives us more time to master user experience design, so that each new site, app, or other digital product we ship is noticeably much better than the previous one. It allows us to become UX experts faster.

2. A product’s users are more likely to end up with a product that they want.

The Lean Startup movement emphasizes the notion of the minimum viable product (MVP). The MVP has only the features that allow a product to be launched. Typically, the MVP will be deployed to only some of your customers: those who are likely to be more forgiving and more willing to give helpful feedback on the product. With fewer features to work on, the project team can focus on making each feature exactly right.

MVP helps companies to understand what customers want more quickly and to focus on developing the right product ideas for serving them best. Later releases of the products can include more features and a wider release.

What that means for you: You’ll know very early in our design process what your users think of our designs. We start our testing with users far before the first release of a product. Many products can be tested with users starting with as little as a sketch. We will use test users who represent your target market well (verified with user research), so that we will take your digital products to market with greater certainty that they will want them.

3. You can ship (and make money from your product) sooner.

This is tied to the minimum viable product (MVP) strategy from the previous point. Because an MVP has fewer features, it does not require as much time to design or develop. This allows the product to be released and sold (or used to help sell other products) much sooner.

Scrum, a widely used agile method which I have also implemented at Thrill & Create, organizes work into a product backlog. The backlog is a list of requirements (features, bug fixes, user test comments, non-functional requirements) that the project team maintains. After the product owner identifies which items need to be in a shipped product, the team needs to work through items on the backlog in order to be able to ship the product. Story points help us to estimate how long everything will take.

What this means for you: If your website, app, or other digital product does not need to be launched in an all-at-once fashion, we can release it in stages. This helps provide you with a fast return on your investment before our team is even done with design and development.

4. Problems are easier to identify and fix early.

Design and development are not exact sciences. User research can help us anticipate what users will want. However, it doesn’t absolutely ensure a correct design. And many software development projects encounter problems that require extensive rework to fix properly.

Fortunately, the Agile Manifesto emphasizes working software and customer collaboration. At a development level, this means that as early in the process as possible, there is always a version of the product that they can ship to customers at a moment’s notice. That version keeps receiving updates as the developers continue to deliver work. At a design level, we test designs with users at many stages to identify problems with their usability and validate which design directions are correct. This allows us to avoid wasting budget developing solutions that do not work.

What that means for you: Your budget will be used more effectively because we won’t spend it going far down the wrong path in our designs.

5. It is easier to allow customers and users to change the product without having the product ship late.

One of the main reasons why agile processes were developed was that waterfall processes respond to change poorly. Waterfall projects often use slow, involved approval processes in order to have changes approved. Teams often have to work at an unsustainable pace in order to ship changes without slipping the project schedule – if that is even possible.

Agile – and in particular, Scrum’s story point system – makes responding to changes easier. Scrum iterations have a fixed duration and a fixed number of story points or hours available. With a fixed timeline, we can use these estimated task durations to determine what makes it into each sprint: new features, bug fixes, testing, and any other work items. Changes that happen often result in lower-priority tasks being removed from the sprint and either deferred to a later sprint or removed from the project. The ship date is only pushed back if the changes do not result in existing tasks being removed from the project.

What that means for you: While we are the designers, we collaborate with you consistently to make sure that you are getting what you and your users need. We are able to accommodate changes in a project in a way that does not jeopardize ship dates as long as our overall project scope remains the same.

How Thrill & Create implements Scrum

At Thrill & Create, we have had different ways of working with our project teams.

When I worked on the Coaster Crew projects, I had one primary and one secondary point of contact with the other Coaster Crew staff. My main point of contact was their webmaster, who also handles the back-end development for their sites. I sent him a weekly status email which detailed what I was working on and whether I was blocked on anything. On tasks that required more involvement from him, we would communicate more frequently via email or Facebook chat. I handled project management and usability test triage using an Excel spreadsheet, which was mainly for my reference.

My secondary point of contact with The Coaster Crew was their vice president of membership. The webmaster and I interfaced with him for more directional-level decisions and budget approvals. Beyond this, I was also able to ask questions or post comments for the rest of The Coaster Crew’s staff to answer.

When I worked on a redesign for a local nonprofit, I initially had a project team consisting of myself as UX designer/PM, a graphic designer, a developer, and an idea guy. We met weekly over dinner to discuss our project and move the project forward. This project was done in a more waterfall-like setting. Due to multiple factors beyond our control, I ended up completing the development myself using a daily to-do list for project management.

I decided to make the rebrand from Dalandan Concepts (pronounced “dah-LAHN-DAHN”) to Thrill & Create a purer application of Scrum processes.

But how do you do daily stand-up meetings as a team of one?

Partway into the project, I created a Daily Scrum spreadsheet with the following columns:

  • Day of week and date
  • What I did yesterday
  • What I still need to do from yesterday (if anything)
  • What I’m doing today
  • What my main project for the day is
  • What iteration I am on in my main project
  • What my second and third projects are (if any)
  • Am I blocked on anything?

I’ve added an entry to this spreadsheet each day since then. Typically, I begin the day by checking my email and doing any other administrative tasks unrelated to my main project. After a break for breakfast, I fill out my Daily Scrum spreadsheet for the day and get into my main list of tasks.

Often, my tasks for the day in Daily Scrum come from my master to-do list. This makes the Daily Scrum process very easy.

Early iterations would be focused on preliminary design tasks, such as user research, persona generation, brainstorming, and sketching. After that, my iterations would usually take the following format:

  • Work on design for items in the iteration
  • Work on development for items in the iteration (Note: For multi-person teams, UX design authors have advised making the design team stay 1-2 sprints ahead of the development team)
  • Draft a list of tasks for user testers
  • Run a round of user testing
  • Write down feedback from each tester, including some metadata indicating which users were closer to our target persona
  • Triage feedback from each tester based on the item’s priority, severity, and level of effort. (Items that multiple users cited and items cited by users with characteristics closest to our target personas’ were given a higher priority.)
  • Determine what would go into the next iteration.

However, my role for the Thrill & Create site was bigger than design. I was also responsible for the site’s development. This made estimation more of a challenge. Several iterations had spikes, shorter timeboxed periods for researching concepts or creating a simple prototype. (Some spikes, such as the ones I did, do result in more features and bug fixes being delivered for the product.) This is why my Daily Scrum spreadsheet has some days listed as Iteration 3.5, 5.5, 6.5 and 7.5.

I also use task breakdowns fairly extensively in estimating the duration of a task. Task breakdowns enable more accurate estimates because they force thinking about the details of finishing a task. Agile methodologies encourage further breakdown of any task estimated to take longer than two days. Incidentally, my biggest lesson learned from the Coaster Crew launch was to not assume that migrating the site from a prototype to WordPress was a short task. Initially, I had estimated it to take 3 days, but the extensive development required for the migration added weeks of work to the project.

The way I do triaging is somewhat different from the story points method in classic Scrum. With the Thrill & Create site, I assigned the effort of work items on a more relative scale. My spreadsheet, then, had columns for priority, severity, effort, and priority times effort. That helped guide me through selecting work items to include in sprints.

The priority and severity scales I use are based on several I found in this Interaction Design Association (IxDA) forum thread. Thank you to Jim Drew for these scales:

  • Severity: Critical: a crash or data loss; users are blocked unless they restart the app or reload the webpage. UX issues rarely reach this level.
  • Severity: High: A major feature is broken and can’t be used fully, or a minor feature is either too broken to use at all or not present
  • Severity: Medium: A major feature can’t be used fully, a minor feature is blocked, or a feature is broken but has a workaround.
  • Severity: Low: The problem doesn’t affect (or only lightly affects) users’ ability to use a feature. An example of this would be poor message wording, or color contrast that meets WCAG AA but not WCAG AAA.

The priority scales I use are based on the following. I adjust them according to how many users are reporting a problem and how close those users are to our target persona:

  • Priority: Critical: This needs to be fixed in this iteration, or other items (priority high or medium) cannot be addressed until a fix for this one is complete.
  • Priority: High: We need to fix this item in this iteration, or at least before we ship the next release.
  • Priority: Medium: We would like to address this item in this iteration or release, but we might not get to it.
  • Priority: Low: We are likely to not do this work item; we only have it in the spreadsheet so that we can track the issue.

As a bonus, here is how I scaled the required effort for a task for the Thrill & Create site:

  • Effort: Extreme: Significant increase to the project scope. Feature is either impossible to build or would require significant development effort or substantial budget/travel to build. For example, one tester on the Thrill & Create site did not like the fonts in several portfolio items. To change this honestly, I would have had to essentially redesign the typography of sites I had already delivered to other clients.
  • Effort: Very High: Bugs that are probably fixable but have a great deal of uncertainty and/or require testing in many configurations. New features that require a great deal of thought and care and/or a full design process to implement properly. For example, comments concerning the overall mood of a site require a thorough review of many aspects of a site to identify the best solution for changing the site’s mood.
  • Effort: High: The work item requires extensive, well-thought-out changes to implement properly and may require new sketches, wireframes, and/or prototypes. For example, when we are asked to change a site’s color scheme, we research new color schemes and test them out in prototypes. High effort could also mean that a bug is affecting different kinds of devices in different ways. For example, the How Can We Help? buttons on the Thrill & Create homepage were displaying unusual behavior around some breakpoints and had to be tested extensively on multiple devices since they essentially required a partial rewrite of a grid system.
  • Effort: Medium: The fix seems simple, but dependencies make it so that we have to make sure it doesn’t break anything else in the site. For example, if the site’s grid system on one page needs more padding at tablet widths, we need to make sure that changing it will not cause undesirable effects on other pages.
  • Effort: Low: Bugs that I already know how to fix when I see them or features that only require a few lines of code to implement. For example, during the Thrill & Create site’s development, the text on the Send Message button was too small. This was relatively high priority but a very simple fix.

Tips for freelancers and teams of one who are considering implementing Daily Scrum

Maintain a Daily Scrum spreadsheet which says what your current projects are, what you did on the previous work day, what you are doing today, if there was anything from yesterday you didn’t get to do, and if there is anything blocking you from finishing today’s tasks.

  • Make it daily: Set a reminder every morning (on work days) to update your Daily Scrum spreadsheet
  • Consistency: Don’t worry if you miss a day. Just make sure you get back to it.
  • Billing: If you do not bill hourly or use value pricing, bill in iterations.
  • Schedule: Timebox the length of an iteration. In other words, if you say at the beginning that an iteration lasts for 3 weeks, keep the length of an iteration at 3 weeks. Don’t go over.
  • Clear communication: Especially if you are remote, always be clear with your clients on what you are working on and whether or not you are blocked on anything.
  • Collaborate: Make sure to collaborate with your clients, especially with your main point of contact. “Here’s your assignment, now go do it and give it back to me when you’re done” is not a way of thinking that Scrum encourages.
  • Minify?: The optimal size for a Scrum team is 5-9 people. If your team has 1-3 people, consider a process with less overhead by replacing some of the meetings with less formal sessions.
  • Remember what it’s for: Use it to stay accountable (to yourself and your client), productive (the point of any good work process), and happy (probably one of your reasons for being in business for yourself).