3

Background

I work at a startup where I'm the only designer (UI/UX/Visual), however, we don't have an actual front-end developer, so most of the HTML/CSS development also falls on me as I'm half-decent at that as well. We have a web app which I and development maintain, but we also have a marketing website that I'm basically the sole maintainer of and I do other design work for marketing as well.

We have a product owner that helps prioritize our backlog, but we don't currently have a scrum master unfortunately, so we're trying to follow a more "program manager" route until we're able to hire one.

We currently practice scrum for our development team, but we're running into issues with trying to figure out how to project velocity since I'm technically apart of 3 different teams—development, design, and marketing.

Question

How do you account for someone that is a part of multiple teams? I realize Scrum by the book says this really shouldn't happen, but when a company doesn't have enough resources, then a person will get shared on multiple teams.

I've seen answers that say you should basically group together people with a certain skill set (such as design or system architects) and have them be a completely different team that has their own sprint where a lot of their tasks will cover work for different teams. Since I'm only one person, that seems a bit overkill, but I can't think of any other possible solutions.

The biggest issue I'm having is trying to make my design process be truly agile as scoring a design can become extremely problematic. Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still technically my priority? Either way, it makes forecasting design to be really hard and if I can't have semi-accurate story points for design, it becomes impossible to say how many points can be allocated doing front-end development stories for the development team project if a design story ends up taking forever due to multiple iterations.

I've heard solutions before that say devote "X percent" to this team & the rest to the other, but the main issue with that is that my time gets drastically shifted from being design-heavy one week to code-heavy the next. So the idea of trying to allocate a certain amount of time to each team just doesn't practically work out.

I would say the work I do shouldn't actually affect the development team, but it currently does affect their work load as they are the ones that do code reviews & test each ticket since I'm only a team of one and can't review my own work. So kind of at a loss for what to do here as I've currently just been jumping from design to coding primarily just based on what I deem to be more important at the moment, which isn't exactly ideal.

Related question: Is it possible for someone to be a member of two Scrum teams, and how can that be made to work most effectively?

6

TL;DR

In your rather long question, this mixture of issues stood out as the gist of what you're really asking about:

Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still technically my priority? Either way, it makes forecasting design to be really hard and if I can't have semi-accurate story points for design, it becomes impossible to say how many points can be allocated doing front-end development stories for the development team project if a design story ends up taking forever due to multiple iterations.

When I parse this, a couple of things jump out at me:

  1. You are consistently taking on stories that can't be completed within a single iteration.
  2. You are carrying unfinished work across iterations, rather than placing unfinished stories into your backlog for re-prioritization by your Product Owner.
  3. You are viewing velocity as a management target rather than a trailing average or a range with a confidence interval.

The problem is only tangentially that you are matrixed across multiple teams; the real issue is that there is no rigor in your organization's iterative process or inspect-and-adapt cycle.

Stories Shouldn't Cross Iteration Boundaries

A story should be completable within a single iteration. Any story that can't be completed within an iteration is generally either:

  1. Incomplete due to improper estimation or unforseen roadblocks.
  2. An improperly-decomposed epic that lacks sufficient granularity.

These stories should be marked incomplete, assigned no points towards velocity or burn-down, and placed back onto the Product Backlog for discussion during the Sprint Retrospective, re-prioritization by the Product Owner, and further decomposition or analysis during some future Sprint Planning meeting when the story is back on the docket.

Unfinished Work is Never Automatically Carried Forward

Any story that isn't complete is "not done." It goes back into the Product Backlog, where the Product Owner may or may not find it relevant to the Sprint Goal of your next sprint.

Even if it remains a top priority, the work should probably not be carried forward as-is. If it was not completed within the sprint, it should be carefully reviewed to determine:

  1. If it was incomplete due to time or budget constraints.
  2. If there was some process issue at play that prevented its completion.
  3. If it was mis-estimated, and how it should be estimated in future.
  4. If it was improperly decomposed, and how it might be broken up into more actionable stories.

There are certainly other things one can review about incomplete work as part of the inspect-and-adapt cycle, but the short list above has generally addressed the vast majority of real-world cases I've run across. Feel free to adapt or invent your own style of introspection; just make sure you and your organization take the time to analyze the root cause of incomplete work, and the cost to the project of leaving any discovered issues unaddressed.

Velocity Isn't a Management Target

Velocity should reflect a team's capacity. If you are working on multiple teams, this will certainly affect the capacity of all three teams, and should be reflected as a visible cost to the projects you're involved with. This cost is most often made visible through a reduction in real velocity over time, a change in the slope of the project's burn-down, or through the number of incomplete stories left over at the end of each iteration. Such visibility is a Very Good Thing™.

It is generally best to calculate velocity as a trailing average over a number of sprints. I personally like to use the statistical mean of the past three months' worth of iterations, but you can use any sliding time box that makes sense for you. If your velocity wanders across more than two standard deviations from the mean, you probably need to revisit your planning and estimation process, along with uncovering any hidden roadblocks that might exist.

The utility value of tracking velocity is that it gives you a measure of confidence in future estimates. If you know that your velocity varies from 5-20 points per iteration, then expecting 20 points of stories to be completed every iteration is simply not a realistic expectation of your current process, but you could probably feel confident about delivering 5 points every single sprint.

When you or your organization start to use velocity as a goal, rather than a detective control to determine if your process is out of whack or a planning tool to determine how many iterations the current backlog will take to complete, then you are using the wrong tool for the wrong job. Velocity is simply statistical data; it is not a tool for developing fixed-scope schedules or delivery dates.

Use your real velocity to determine how many iterations you are likely to need to complete a given set of stories. Your Product Owner can then adjust the project's scope to change the number of estimated iterations required to meet management goals, but he can't manufacture velocity (incorrectly pronounced "productivity") by gaming the numbers.

Keeping Costs Visible

No invisible work, ever!
— CodeGnome's Law of Transparency

When you say that it sometimes takes five iterations for some design element to be approved, that isn't inherently bad. Iterative development often means things get refined or redone multiple times. However, if designs aren't being completed during a single iteration, it often means there's a process problem such as a lack of cross-functional team skills or a poorly-designed feedback loop in the design process.

Whether the multiple iterations to refine a design are good or bad is a judgment call for the organization. In either case, they represent a cost to the project, and this cost should always be visible. If it's simply the cost of doing business in your organization to do multiple redesigns, then this should be looked at as an acceptable cost, and there's no reason to sweep it under the rug. If it's considered sub-optimal, then the organization needs to keep that cost visible as a constant reminder that the relevant processes should be inspected and adapted until the cost becomes acceptable.

Visible costs are the grease that keeps the agile wheels turning smoothly. Costs that are higher than expected are a call to action, and their existence means that your process is properly detecting those higher-than-expected costs. This is not a process failure, but a process opportunity. Treat it as such.

  • TL;DR right back at you. – GaTechThomas Mar 7 '14 at 22:57
3

Looks like your Scrum team does not have a Product Owner nor a Scrum Master

However, if you do, get your Product Owner to prioritize the stories and get your Scrum Master to receive and manage all requests for your time. Your team (and you) should focus on one highest priority story (as decided by your Product Owner) at a time and take it to 'done' status. Now to respond to your specific questions:

How do you account for someone that is a part of 2 different teams?

A scrum team should be able to deliver a "potentially shippable increment". So, no, it is not a good idea to have one team for design and another for development.

it makes forecasting design to be really hard and if I can't have time estimates for design, it becomes impossible to say how much time I can spend doing front-end development for the development team project.

Don't try to estimate in hours, do the estimation in story points. All software work has some uncertainty built-in. You cannot eliminate that uncertainty. At best your team can try to improve your estimation based on what you have learnt from previous estimates. Work on the highest priority work (as decided by your Product Owner) first. Once that is done, move to the next story in priority. And discuss the design approval process in the retrospective and see if there is anyway to improve it.

the main issue with that is that my time gets drastically shifted from being design-heavy one week to code-heavy the next.

What is wrong with that? Your team's goal should be to deliver the features prioritized by the Product Owner - not keep you fed with design and coding work very evenly.

I've currently just been jumping from design to coding primarily just based on what I deem to be more important at the moment.

That is exactly what Scrum is designed to avoid. Context switching kills productivity and grows frustration. Refer anyone who wants your time to the Scrum Master.

Is it possible for someone to be a member of two Scrum teams, and how can that be made to work most effectively?

I have worked with a database developer who was a member of more than one scrum team. Resource contention and priority across multiple scrum teams can be resolved in a Scrum of Scrums meeting between the Scrum Masters and the Product Owners of the two teams. You focus on doing the prioritized work on hand. You also update the remaining hours to complete open tasks on a daily basis.

  • Made some updates & clarifications. I often errantly use "time estimation" to mean story points. I understand & already agree with much of what you're saying, so that's not really my issue. It's more to do with me not understanding if the marketing team has a scrum team (they're looking into actually adopting scrum…) and development is a team and I'm on both teams due to lack of resources—how do either teams project velocity if I'm needed more for marketing one sprint & dev the next. It almost seems like I need to determine my personal velocity, so they can adjust the team's velocity. – NerdCowboy Feb 25 '14 at 23:07
  • 1
    See my answer to your added question. There is no such thing as a personal velocity in Scrum. – Ashok Ramachandran Feb 26 '14 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.