What options do we have to integrate a UX/UI team into our Scrum process?

Although this question doesn’t come up all the time, it certainly comes up enough that sharing how our team made the decision to keep the Design team work outside our scrum team’s sprint could be helpful to others.
Just to give you some background, this team has been focusing on the intake of new projects, how we define new projects and what information is needed to ensure we make good business decisions in the future.  And, since this post references some processes in a previous post, you may want further clarification, so check it out here.
Our team has had many organizational changes over the years so we decided to take time to evaluate our agile practice and our teams to see how they were doing.  During our reviews, we heard that our design team wanted to understand how they would participate in our scrum practice and previous attempts weren’t going well.  So, to keep our discussion simple and make a decision quickly, we had leads from Product, Design and Tech review two options that we could use to plan and execute with consideration for how design/UI/UX is integrated into the process we continue to evolve.  Take a look and come prepared with your input on which option you believe works the best for your team.
Each option assumes…
…for each new project that is approved and moves to the “COMMITTED” status, we will have release planning with all teams invited (product, design, tech, ops, etc.) before we begin so that everyone understands the goal of each release (if there is more than one per project) and what high level features are being requested.  
…at the end of the release planning session, each team comes up with their estimated schedule to complete the project and each release/milestone along the way. This is the way we create the CPE (Concept Phase Estimate) and projected completion date and the project moves to the “READY” status in our Intake workflow.
Red text represent the variance between options
Option 1 = Design iterations of a user story are done prior to team sprint planning
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team that will be part of the next engineering sprint planning session
  4. Iterate with Design until each user story from the first set is ready with all required information for engineering to begin
  5. Product Owner presents the user stories along with lead Designer at the engineering sprint planning session
  6. Sprint commitments are made on which stories engineering can complete in the sprint
  7. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  8. Design and Product continue to work on the next set of user stories during this sprint that will be presented at the next engineering sprint planning session
  9. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance
Option 2 = Design and Dev of a user story is done in same sprint
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team and the Tech at the same time during the sprint planning session
  4. Sprint commitments are made on which stories Design and engineering can complete in the sprint
  5. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  6. Design and Dev are done in parallel on the same stories during the sprint
  7. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance

Early in the discussion, most people were already on board with Option 1 but we continued to discuss examples so that we all understood how it would play out in the day to day ceremonies that our teams already had such as Release Planning, Sprint Planning and daily stand ups.  We agreed that leads from Product and Design would continue to attend the sprint planning and daily stand ups as needed by the team.


Agile Ceremonies

NOTE: Since this post references project workflow and you may want further clarification, check out my other post regarding project workflow here.
Please take a look at the summary below which explains the type of meetings and practices throughout the lifecycle of our projects that we’ll be focusing on improving and adjusting as we grow as an agile organization.  Remember that every team and organization customizes things to match how they work so this is not meant to be prescriptive. Use it as a guide and go from there with your team.SAM_1313

Yes, We’re Agile but we still Plan, right?

Yes, of course you still need to plan – even when following some type of agile method. It still amazes me that so many organizations stop doing this. Some don’t it because they believe that agile means no planning and some don’t it because … well, there are so many other reasons. Is it really worth repeating?  Maybe I’ll do another post about that, but for now, let’s look at one team established an intake process for new projects and made it simple yet effective.

000 Blog Agile Topic Photos - 10


Before our teams begin working on new projects, we need a way of ensuring that there’s a solid business case to do it and a clearly defined scope of features or benefits.  Sounds like planning right? Well, you could say that but, actually it’s before we even start really planning; we’re evaluating, we’re justifying, we’re using the ROI (Return on Investment) model to ensure we are pursuing the right project in the right order (priority).

Let’s look at the scrum model for a moment.  Each sprint starts with a fully formed group of user stories in the backlog that are “ready” for the team to start working on them right?  Well, how do you know that those stories are really the right ones to pick up next?   We started by tracking backwards from the backlog to build a process the supported how we were working and kept us in an iterative learning state of mind.  The image here shows the process or workflow that we are using.

The Product Owner is constantly evaluating current progress against the backlog of new ideas.  Once they have something to present, they prepare a proposal that includes key data points of their research and ideas in the form of business justification and benefits to the company and our consumers. We ask for 1-3 sentences describing the end result of the project.  It should address questions like “Why are we doing this?”, “What is current problem statement or potential improvement and what is the expected outcome at the end of this project?”  Along with this justification, we also ask the Product Owner to detail the benefits to the company and/or our consumers by providing either target or concrete goals for the project that fall into categories like Cost Reduction, Revenue Generation, UV Lift, PV Lift, Brand Lift or Efficiency Gain.

This provides everyone reviewing the proposal a clear understanding of the why they may want to approve the project to be approved and funded.


If a proposal is approved, it is moved to a “Committed” state where the teams involved do a release planning session so that all the impacted teams (internal and external) are able to evaluate the size of the work and the interdependencies between team as well as other projects that my have higher priority to agree on a projected start date, completion date and estimated cost.  Those data points are provided back to the approvers to ensure that the ROI is still positive.  If everything still looks good, we move the project to “Ready” and each team picks up user stories from the Product Owner for their sprint planning sessions.

Not every project begins immediately after the release planning is completed but we try not to allow too much time between the session and the project actually starting.  There are cases where a proposal is approved but it’s low enough on the project priority that it could be months before we are able to start working on it so we delay the release planning to be closer to the start date. We move the project to “In Flight” once work begins and place it in “Deferred” status when and if the project is put on hold.

Notice that even after a project is moved to “Complete” it’s not all the way through the project workflow.  This was an important step in  iterative learning and decision making that we added after a few months running the projects through the workflow.

Some of our project leads were reporting that even when the final production installation was completed, the benefits that were expected from the project would not be true until several weeks or months afterwards.  And no one was going back to evaluate the results of the completed projects to verify that the benefits had actually been achieved and to what degree.  That was the beginning of our Project Retrospectives.

If you think about how Scrum teams do team retrospectives to determine what changes were working and which ones weren’t it makes total sense that as a business, you’d want to do the same with projects.  Every month, we began retrospecting about each project that was completed in the prior month.  The team members were encouraged to present the results and we started to see improvements in several areas not just in the new project submissions but also in the cross pollination of product knowledge across the organization that did not have a venue in the past.  People were curious about why we were doing certain projects and now they had a space to hear the results, see the bigger picture and feel how each of them were part of the overall goals.

Once we completed the retrospective for a project, we move it to “Benefits Realized” adding the results so that we can reference it in future project proposals. Here is a template that was used for each project retrospective.  Note that our company uses the capitalization accounting practice so it’s also evaluated.Image

Agility is about the ability to react quickly when necessary and appropriate.  So yes, we plan and we are still Agile.  We use the intake workflow to keep us in the cycle of learning and adapting.  We’ll likely make adjustments as we evolve as a team but for now, this is reminding us to keep watching if we’re going in the right direction and allow the agility of the teams to respond as we learn and adjust our business roadmap.

No Scrum Master? Is it still Scrum?

What happens when the team gets all the training about Scrum, begins to kickoff the process but they don’t have a Scrum Master?

There are arguments (some legitimate and some not) to justify why Scrum will work without a Scrum Master. First, let me say that a Scrum Master is a role not a title so there really shouldn’t be any restrictions on who can fulfill the role.  Second, someone should take on the role and really dedicate time and energy to give the team the support they deserve. Check out Mike Cohn’s blog about Rotating the Scrum Master Role.

SAM_2306So what work does a Scrum Master do that now needs to be covered by someone else or the team as needed?  There have been a number of response to this question all over the internet and books so you’ve all probably heard that standard answers of remove impediments, champion the process, shields the team from outside interferences, etc. but I’d like to take it a step forward or maybe sideways.

Scrum Masters are champions for the team, their decisions, their delivery and even their failures. They are constantly looking at how the team operates from both an internal and external lens; one that the team members are very rarely able to use because they are in the thick of things and may not have the objective eye.  When a Scrum Master is able to identify things that are impeding the team and help them discover it rather than point a finger, jump up and down and demand they fix it, a bond is developed between the team members that gives them the confidence and trust that someone is looking out for them and is there to help them achieve their next level of expertise.

Eventually, a Scrum Master should find that the team needs their guidance less and less over time.  There are a few exceptions to that.  Teams that are dispersed  teams that gain new team members, teams that experience growth and then split (scaling scrum) will need more time and attention from their Scrum Master during these times.  They may have been experts at their process and become self managing but anytime the dynamic changes, there will be more to talk about, more to decide on and generally shakes the team for a time.

Another thing to note is that Scrum Masters are not Project Managers or even Tech Managers in their primary role.  There is a tendency to do this and it’s a dangerous thing because it can taint decisions and imply a level of power and control that should be absent from a Scrum Master.  Members of a scrum team should continue to rely on their managers and peers to improve their level of skill and professional growth whereas a Scrum Master may notice and relay recommendations about team members to their manager as a way of keeping the health of the team and growth of the team moving in a positive direction.

Hope this helps some of you!

Coach in Manager’s clothing…errrr what???

It is not a new question to ask who should be the Scrum Master when you’re starting a new team or beginning to use Scrum in your existing team. There are so many different opinions and advice on this that when I reached out to my fellow agilists, I got a lot of different answers. My friend and agile coaching mentor, Eric Willeke, sent me a link to Ester Derby’s blog post that speaks about the qualities, the warnings and her experience with different choices in choosing the right Scrum Master.

Daily meeting blues? How about shaking it up?

Whether you’ve just started agile with your teams or you’ve been doing it for a while, at some point people may question the value of the Daily Stand up, Daily Scrum or Daily meeting.  People start missing the meetings, arriving late, taking calls, the meetings go over the 15 minutes or start sounding more like a status report instead of the format that Scrum advised us to use.  Jason Yip blogged in Augustabout how to reevaluate the format, watch for patterns and offers some techniques on how to improve them.  There are some great tips here if you want to keep the same format.

This has been the standing Daily Stand up format:
  1.     What did I accomplish yesterday?
  2.     What will I do today?
  3.     What obstacles are impeding my progress?

If the meeting isn’t working for the team anymore, it should come up in the retrospective.  But, if it doesn’t, the scrum master should probe into this directly to get the team to find out WHY it’s not working.  Before revamping meetings or canceling them, always always always find out why first.  There may be a totally different reason than you know and asking the team may be a revelation to you and to the team on how to fix it.

If you’ve ruled out basic things like attendees, room location, tangents and the format just doesn’t work for your team. I’m here to suggest a small simple change.

As each person speaks, they state only the following:
“Today my plan is to _______.”  and if needed followed by “and I will need ____ today to do it.”

This captures their responsibility both for the work they will own today and help they need today.  It’s a simple change but as their Scrum Master, you should listen for ambiguity, overlapping work or people without clear direction so that you can follow up with them to offer help and/or their manager with feedback.

Timeboxing the Sprint Review, Retro and Planning in a Single Day

Prep work for the Project Manager, Scrum Master or the like:

  1. Break the meeting scheduled in calendarto explicitly time box the Sprint close from the Retro (maybe two separate meetings in calendar)
  2. Have a set agenda posted along with detailed descriptions as noted below (Customize as you like as a team) for the Sprint Close out and Retro sessions as a reminder of the flow of the meeting.  Posters or even a wiki page with the info is good.
  3. Move any retrospective item that you accomplished in the last sprint from the improvements/retro poster to a “completed improvements” poster so you can reference things you did and agreed to do over time.

Sample agendas for the last day of the sprint:

  • Team Prep Night before Sprint Close out
    • Remind the team to close out any task(s) that they completed in advance so that all you have to do during the Review meeting is do the QUICK CLOSE on any stories with zero remaining hours at the story level. This will set status to Done and zero out the remaining hours of the task in one click
    • Confirm any unfinished tasks/tests that are not done, update the remaining hours, make the task estimate the same number as the new remaining hours number (this helps with capacity planning for the next sprint)
  • 930-10am Sprint Review and Close out
    • Confirm which story and defect is complete (QUICK CLOSE the story)
    • SPLIT any partially completed story to move the unfinished tasks/tests to the next sprint and then
    • After everything is done (sprint closed and new sprint activated), this is when you can move into the RETRO section to talk through why the team is completing more or less story points each sprint.  If an idea comes up during this discussion, this is a perfect time to slide into the Retro portion of the day
  • 10am-11am Sprint Retrospective
    • Review the VELOCITY TREND report on the  Sprint Planning/Sprint Scheduling section and discuss what the team is doing that is causing the trending to be what it is. Are there some improvements they could be making to improve it? Are there some things that the team is doing that is making a positive difference to the trending?
    • Look at the Retro poster (or wiki) to see what improvements the team has talked about in the past. Are there new ideas to add? Has the team completed some of the items already? CELEBRATE them!
    • Vote on which item(s) the team would like to tackle in the next sprint. Maybe there is more than one that can be accomplished?
    • Add a story card to your sprint backlog for each item the team agrees they want to add and assign the owner(s) that will be responsible for doing the work it will take to make the improvement and/or providing updates on it throughout the sprint as requested.

11-Noon Product Owner/Scrum Master Prep Session

    • Add new stories to the sprint backlog that should be considered in sprint planning
    • Remove stories that should be moved out of the sprint
    • Review any blocks, issues or impediments to resolve them or pull stories out of the sprint if they are not resolved yet
    • Prioritize the sprint backlog (will review again with team at the sprint planning session)
    • If time permits, plan out the stories a few sprints ahead as a “request” to the delivery team and to assist with forecasting/scheduling
•    1-4:30pm Sprint Planning (entire team include Product Owner)
  • 1-1:45pm – Story walk through and Estimation
    • Product Owner walks team through the stories they would like to consider for the sprint, should include the story description, user acceptance criteria and stop to add more detail or to explain any new stories that need additional information so that the team will be able to size/estimate the story
    • Team members “sign up” for stories they would like to work on (add themselves to the OWNER field on each story)
    • Team sizes each story after all have been reviewed based on relative sizing technique (“smaller than this, bigger than that”)
  • 1:45p-3:45pm – Story Detailed Planning
    • This time is informal and time to self-organize!
    • People tend to group together as needed by story to detailed out the tasks that each person will be doing on each story, entering the tasks/tests as they discuss and then estimating the hours for their work
    • Each team member should look at the Sprint Planning/Member Planning page to see who is over allocated based on their assigned work against their offered capacity.  Talk to other team members to help them out by discussing how to spread the work more evenly across the team.
  • 3:45p-4:30p – Sprint Plan Commitment and Kickoff
    • Review the Sprint Planning/Member Planning to ensure no one is over allocated
    • Review the total story points planned for the sprint – Is it higher than the trending velocity? It’s ok to go a little higher if work was partially finished in the last few sprints but the completed story points were low because of splitting.  Just remember to keep your new sprint somewhere between what you did and what you planned last time so you have a better chance of doing it!
    • Do a fist of five vote on the final sprint plan and you are ready to kick off the sprint!

Fist of Five Voting for Team Consensus

Fist to Five is quality voting. It has the elements of consensus built in and can
prepare groups to transition into consensus if they wish. Most people are accustomed to the
simplicity of “yes” and “no” voting rather than the complex and more community-oriented
consensus method of decision making.  This moves a group away from quantity voting to quality voting, which is considerably more informative. Fist to Five can also be used during consensus decision making as a way to check the “sense of the group,” or to check the quality of the consensus.First, a member of the group presents the details of the proposal. This individual will then answer “clarifying questions” until all such questions have been asked and answered.  If appropriate and helpful, the group may then open the floor for discussion or break into small
groups for discussion. (If small groups are used, when the large group is reconvened, time should be allowed for any clarifying questions or comments members would like to include before voting.)The Initial Vote
Once the proposal presentation is completed, the facilitator will direct each team member to vote by holding up 0 – 5 fingers.

  • Fist: No support–will work to block proposal. “I need to talk more about the proposal and require changes for me to be comfortable with it.”
  • 1 Finger: No support, but won’t block  “I still have strong reservations and want to discuss certain issues and suggest changes that should be made, but I agree not to block the proposal if approved as is.”
  • 2 Fingers: Minimal support”I am moderately comfortable with the proposal as is, but would like to discuss some minor issues.”
  • 3 Fingers: Neutral  “I’m not in total agreement but feel comfortable to let this decision or proposal pass without further discussion.”
  • 4 Fingers: Solid support “I think it’s a good idea/decision and will openly support it.
  • 5 Fingers: Strong support “It’s a great idea, and I will do all I can to promote it.”

If there is not a full consensus, ask the individuals that voted differently than the majority to state their concerns to the entire group including what it would take to get them to vote with the majority. After each individual has shared, the floor will be opened for clarifying questions, comments,  and discussion. The facilitator may choose to set time limits.

Once each minority voters has stated their case, another Fist-to-Five vote is held for the final version of the proposal.

Scrum Tuning – Google Experience

%d bloggers like this: