There Is No Sprint Zero. GO!
-
Upload
tonya-mccarley -
Category
Technology
-
view
124 -
download
0
description
Transcript of There Is No Sprint Zero. GO!
Over a year ago, I started on an new and interesting journey. I was assigned to work on an Agile team.
I came from a traditional waterfall background. I had a clear understanding what my role was on the team. What my deliverables were, how long it would take to create them.
My world was very straightforward then.
My exposure to agile prior to my current role was academic. There was this thing called sprints, where developers did short bursts of work, and then they would iterate. And UX work all occurred in this thing called Sprint Zero. Before the dev teams start working.
This presentation is my experience about being embedded in an Agile team and being immersed in the process. As you can imagine, this was quite the change for me. Interestingly enough, both change management and agile talk about the Five Stages of Change adoption.
This is based on the Five Stages of Grief.
I will use this model to share my experience.
D E N I A L
Denial
For me, denial often presents itself as optimism. Hey, Agile is new for me, but I would really like to learn about it. I’ll still be able to do my usual process in the mystical Sprint Zero.
Not the case.
D E N I A L
Denial
For me, denial often presents itself as optimism. Hey, Agile is new for me, but I would really like to learn about it. I’ll still be able to do my usual process in the mystical Sprint Zero.
Not the case.
O P T I M I S T I C
Denial
For me, denial often presents itself as optimism. Hey, Agile is new for me, but I would really like to learn about it. I’ll still be able to do my usual process in the mystical Sprint Zero.
Not the case.
I am part of a Product Team. The product team is made up a lead from each functional group. There is a dev lead, a UI lead, a QA lead, myself as the UX lead and the product manager along with the Scrum Manager.
We created the Initial backlog together. This enormous sprawl of sticky notes is a our project? This is the documentation? This is the map we’re going to follow? No requirements, no speciRications?
JSTOR HOME SEARCH BROWSE MyJSTOR
<Coverage>, <Volumes>Published by: <Lorem Ipsum Press>
Books in Series
<Series Title>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci malesuada diam, quis dignissim leo augue eu risus. Duis bibendum, dui sit amet suscipit pellentesque, felis tortor auctor augue, ut dapibus ipsum urna in velit. Sed ultricies varius nibh at aliquet. Mauris vehicula mi dapibus mauris tempus posuere. Vivamus dapibus condimentum nulla a vestibulum. Nam lorem arcu, vulputate sed varius vel.
Month Year<Title>
<Author>Stable URL: http://www.jstor.org/stable/xxxxxx
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.
Month Year<Title>,
<Author>Stable URL: http://www.jstor.org/stable/xxxxxx
Month Year<Title>
<Author> Stable URL: http://www.jstor.org/stable/xxxxxx
<Subtitle>
<Subtitle>
<Subtitle>, <Author>, <Author>
1
4
3
7
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci.
Notes: List of Series/Sets (LOSS)
BLUE = BKS-89
1. Series Title is NOT clickable.
2. Coverage: span of years. Format will be YYYY-YYYY.
Computed based on the first published year of a volume in a series and the last published volume in a series.
Volumes: total number of volumes in the series: X Volumes
Publisher: name is clickable and goes to the Publisher page.
3. Books in Series:
The volumes are shown in the order of the published date, with the most recent first.
Each book may contain the following information:
Title: On click, goes to the book TOC.
Subtitle: OPTIONAL. If a subtitle does not exist, do not show an empty row.
Authors: Not clickable from this page
OPTIONAL: If more then one Author, they are separated by comma.
STABLE URL: Not clickable
Brief snippet: First 50 words of book blurb.
ORANGE = Separate Cards
4. Series Summary: X characters long.
If no summary, page content moves up.
This MAY be future content.
5. Access Key:BKS 91Should work as it currently does.
6. Access Icons: BKS-92Should work as it currently does.
7. Global Search: BKS-93Should work as it currently does.
2
6
5
, <Author>, <Author>
, <Author>, <Author>
J
B
J
J
J
J
1
Notes: This is first pass and the icons attached are not the final icons.
Success Criteria: An icon appears in the top right corner of each search result that indicates that it is a Book, Journal, or Pamphlet. These graphics should meet accessibility standards.
And I was creating what I will call JIT wireframes. Instead of trying to understand the entirety of the functionality of the work upfront, I was creating very discrete artifacts to illustrate stories.
Learning to create in terms of “passes” and “not perfect” Pulls dev into the process earlier
A N G E R
Anger (I’ll call this frustration)
The Product Team experiences a lot of churn. As we plan sprints, we are pulling stories out of the backlog that we had an understanding of “way back when” but may have lost the full meaning of it in the now.
This feels inefRicient to me. If we had written things down more completely “way back when” then maybe we wouldn’t have to spend hours trying to Rigure out what that sticky mean.
Tension with the dev team. It turns out they want pixel perfect wireframes.
A N G E R
Anger (I’ll call this frustration)
The Product Team experiences a lot of churn. As we plan sprints, we are pulling stories out of the backlog that we had an understanding of “way back when” but may have lost the full meaning of it in the now.
This feels inefRicient to me. If we had written things down more completely “way back when” then maybe we wouldn’t have to spend hours trying to Rigure out what that sticky mean.
Tension with the dev team. It turns out they want pixel perfect wireframes.
F R U S T R AT I O N
Anger (I’ll call this frustration)
The Product Team experiences a lot of churn. As we plan sprints, we are pulling stories out of the backlog that we had an understanding of “way back when” but may have lost the full meaning of it in the now.
This feels inefRicient to me. If we had written things down more completely “way back when” then maybe we wouldn’t have to spend hours trying to Rigure out what that sticky mean.
Tension with the dev team. It turns out they want pixel perfect wireframes.
B A R G A I N I N G
Bargaining (Resigned)
With each sprint review, I’m beginning to better understand what the developers need from me. And we
It becomes a negotiation. During sprint planning, making sure my deliverables are clearly marked up and expectations are set. And Rinding a common language. The new language involves stating explicitly this is a “Rirst pass”, it is not a “perfect representation of the Rinal product
B A R G A I N I N G
Bargaining (Resigned)
With each sprint review, I’m beginning to better understand what the developers need from me. And we
It becomes a negotiation. During sprint planning, making sure my deliverables are clearly marked up and expectations are set. And Rinding a common language. The new language involves stating explicitly this is a “Rirst pass”, it is not a “perfect representation of the Rinal product
R E S I G N E D
Bargaining (Resigned)
With each sprint review, I’m beginning to better understand what the developers need from me. And we
It becomes a negotiation. During sprint planning, making sure my deliverables are clearly marked up and expectations are set. And Rinding a common language. The new language involves stating explicitly this is a “Rirst pass”, it is not a “perfect representation of the Rinal product
While the product team sizes the story, the dev team writes the tasks it will take to meet the speciRied success criteria. If the story involves a UX component, I make sure the team understands the intended functionality and as many of the rules for that story. And sometimes, they know more than I do. We enter a collaboration.
Understanding the scope of the “story”
And I am with the team throughout the entire process. I don’t work on deliverables for a few weeks and disappear. I only recently return to my cube to work on my deliverables. I work in the colab WITH the developers and the Product Team in an open collaboration space.
Insert photo of colab space. Dev team and product team
D E P R E S S I O N
Things are going well, but I can’t get comfortable. I look at the backlog which we have now mapped out against all of our sprints.
D E P R E S S I O N
Things are going well, but I can’t get comfortable. I look at the backlog which we have now mapped out against all of our sprints.
W O R RY
Things are going well, but I can’t get comfortable. I look at the backlog which we have now mapped out against all of our sprints.
I’m anxious. I can’t trust in this process. Looking at the amount of work we have to do with NO requirement or specs is making me nervous. But my team keeps reassuring me that we don’t need that documentation.
Insert backlog breakdown slide
A C C E P TA N C E
Acceptance
As this project progressed our business model changed. This forced a change in the requirements, the technology, and the workRlow. Assumptions we started off with were no longer correct. With each change I began to realize that it was a good thing that I hadn’t spent hours, maybe weeks, deRining something that no longer existed. Rather than wasting that effort, the entire team was able to adjust and course correct with little sunk cost.
I began to accept that this process was working.
While the product team sizes the story, the dev team writes the tasks it will take to meet the speciRied success criteria. If the story involves a UX component, I make sure the team understands the intended functionality and as many of the rules for that story. And sometimes, they know more than I do. We enter a collaboration.
Understanding the scope of the “story”
Even it it’s not perfect the dev team still looks to UX for direction on rules and edge cases
UX is an INTEGRAL part of the process Liked image
TONYA [email protected]: TMCCARLEY