|
Original Broadcast Date : Wednesday, June 8, 2011  
Duration: 12:30 AM PT / 2:30 PM CT / 3:30 PM ET
Speakers:
Bob Gower, ScrumMaster & Agile Coach, Rally Software
Craig Langenfeld, Product Ambassador, Rally Software
Geoffrey Bourne, SVP, Major NYC Financial Institution
User Stories, designed to keep teams laser-focused on customer needs, serve as THE driving force behind delivering valuable, high quality features, fast.
Key Takeaways:
-
Examples of breaking down stories while keeping the focus on customer value
-
The way to write acceptance criteria and define "done."
-
The differences between stories and tasks
-
Suggestions for improving size estimates
-
How user stories relate to the product roadmap
-
Lessons learned from your peers
About the Presenters:
Bob Gower,
ScrumMaster & Agile Coach,
Rally Software
Bob Gower is an Agile Coach with Rally Software. He is passionate about helping teams move faster, build better products and get happier along the way. With more than 15 years in management Bob first entered the software world in 1998 directing design and UI on projects for companies like 3 Com and Elance. In 2005 he discovered Agile principles and has been focused on helping build collaborative systems ever since. Bob holds an MBA in Sustainable Management and believes that building collaborative, self-organizing teams is not only essential to success in business, but also an important component of a sustainable future. Bob lives in San Francisco's mission district and can frequently be spotted in the amazing restaurants the area has to offer.
Craig Langenfeld,
Product Ambassador,
Rally Software
Craig Langenfeld is a Product Ambassador for Rally Software in Boulder, CO. Since 2000, Craig has held such titles as developer, project manager, instructor, scrummaster, tool expert, and friend to those who are driving organizational change and seeking better ways to deliver software. Recently he has focused his efforts on building a community and sharing best practices for Agile software development within High Assurance industries. He is also passionate about scaling Agile practices and tooling within large enterprises. Craig earned his bachelors degree from Northern Iowa University and currently holds PMP and CSM certifications.
Geoffrey Bourne,
SVP,
Major NYC Financial Institution
Geoffrey Bourne has over 13 years of experience in the financial IT field, having worked at J.P. Morgan, Goldman Sachs and several start-ups. He has spent many years managing globally distributed Agile teams, and is the co-author of the upcoming Addison Wesley book Agile Answered. He has a B.S. in Computer Science from Washington & Lee University and is a certified Sun Java Developer and PMP. Geoffrey is currently a Senior Vice President at a major financial institution in New York City and manages the Private Bank, Personal Wealth Management, and Corporate Agile mobile groups. He can be contacted at gbourne@gmail.com
Presentation Transcript:
Well, good day everyone, and thank you for joining us for our User Stories Webinar today. My name is Drew Jacobs and I'm a member of the marketing team here at Rally. And I'll be playing a little bit of an MC role. This webinar is the second in our enterprise Agile series, which will be playing throughout a good part of this year.
And you'll see throughout this series we'll be addressing both core Agile concepts like this one, as well as more enterprise level and advance topics like multi-team release planning and kanban a little later in the summer. In the room here today I've got two of my colleagues, Bob Gower and Craig Langenfeld.
Bob is an Agile coach here at Rally, and has worked with many of our customers, large and small. Craig is a technical account manager, and he's going to spend a little bit of time today showing how Rally supports some of the concepts we're going to talk about here. And last, but certainly not least, we have Geoffrey Bourne, joining us from Citibank.
Jeff is a Senior VP there and has worked really closely with Bob on some Agile projects at Citibank. He'll be sharing a lot of his stories and lessons learned during the web cast today as well. As an aside, too, he is writing a book on Agile, and his book entitled "Agile Answered" is due out in 2012.
You can look For that, for Madison Wesley. So thanks, Jeff, for joining us today.
Thanks, Drew. This is Bob Gower from Rally Software and I just want to start out with a little bit of agenda, some housekeeping. So we are going to focus on why, just like a good user story starts off with a why, we're also going to start off with why user stories. We're going to look a little bit at user stories at the enterprise level and actually, that content's going to be distributed throughout this particular webinar.
We're also going to cover story basics. And then, where we really dig into the details in the end is going to be refining the stories and decomposition, which is really the critical skills you need in order to write excellent user stories. So, a little just about, you know, my story: I started off in working with start ups. That's where I learned to write user stories. And I realized very early on that if I was, well, after having used stories for a while, that if I was to have used stories earlier on, that I could launch products much, much faster.
So, speed was really important to me. And the reason I think speed to market - user stories focus on speed to market ,or affects speed to market, is because they allow us to focus on value. And they allow us to instead of developing sort of everything and anything and everything, they allow us to develop just the things that really add value or determine what really adds value to our market.
So this, of course, means that there's a lot of waste in our software. And one of the things I got really curious about was, what other companies or who else was experiencing this level of waste? In other words, developing features that weren't really used or they were misused as in the picture here.
So this is going to lead us into our first poll, which is: what percentage of software features are rarely or never used? And we have three choices here. We have less than 50 percent, about 64 percent, or over 80 percent. So why don't you go ahead and answer that and we'll see what we've got. Oh, we've all ready got some answers coming in.
Let me push these out, so you guys can see them. And let's see if we have any more. All right, yeah. So it seems like a lot of us have all read this particular survey before. And, yes, it's 64 percent. According to the Standish Group, it was a poll of some eight thousand software applications, done back in 2006, about 64 percent of software features, they're rarely or never used and this, of course, represents the biggest, sort of, waste within in our industry.
So, it's not surprising a lot of big companies are turning toward Agile. I, like I say, my background as a product owner was in the Silicon Valley start up culture, but also it's definitely entered the enterprise level. It's just one of the reasons I was so happy to invite Geoff Bourne here today.
So, Geoff, we talked a little bit earlier, sort of about valuable software. And the idea is that we're not talking just about working software, but we're talking about valuable software. I wonder if you could sort of weigh in on some of this intro here.
Sure. Thanks, Bob. So, at Citi we try to focus on creating a lot of business value in everything we deliver. And I'll relate a story that's kind of an interesting example. So one of my teams, one of my Agile teams, actually does iPad development. And when we first started the projects, one of the user stories created was, well, we have some documents that are in simplified Chinese.
We should support simplified Chinese. Seemed pretty obvious. And everyone's agreed, absolutely put this in.
To this day, ten months later, we still have that story on our product backlog. And it has not been done, which believe it or not, is a good thing. That means that higher priority, higher business value items took the place of doing, what in hind sight now, was a lower priority of adding in the multiple languages.
If we had used the traditional waterfall of ERD, we would have absolutely put this item in for multiple languages. We would have developed it because it was in the requirements document. And it would have been delivered. But, in its place another feature of higher business value would not have been done, given the same constraints of scope and timeline. So, that's just an example of how using stories, using Agile, using the product backlog has really helped us focus on creating the most valuable software.
Right. So, and I think to your point, really what we're talking about with user stories is we're talking connecting the vision of the product or the vision of the company all the way down to, sort of, a daily task level, to what's actually being worked on. And the user story is sort of the medium of communication that I see that we use all the way through that.
Now traditionally, of course, we've used just large requirements documents. And I know a lot of the people on our call today have experienced or are currently working in an environment that uses large BRD's, PRD's, whatever you may call them, but the more traditional up front requirements documents.
And what I'd like to do is actually poll our audience again and find out, sort of, how satisfied you are with that traditional way of doing things. So, you'll see a poll now coming up on your screen. Just how satisfied are you with traditional product requirements documentation. A is you love them, B is you neither love nor hate this sort of - you're very neutral towards them, C is big requirements don't inspire my confidence. And I guess there may be a D, but we don't have that option for that. So, let me see. Looks like we have some results coming in. I'm going to push these out so you all can see them as they come in.
So, we have a small sub-set of our audience, does seem to love requirements documents, which doesn't surprise me, there are some good things about large requirements documents. A lot of people seem fairly indifferent, but it seems like over half are not so inspired by the confidence of them or by confidence in requirements documents.
Yeah, about 58%.
So, Geoff, I wonder if you could talk a little bit about your experience. I know you've worked in a sort of heavy requirements stock world. You have also worked in an Agile more story based development world. What's been your experience with the big requirement stocks?
I've always found that the requirement documents, they give a very nice, secure feeling.
If you have a big document, something you even printed out, it looks very much like you spent a lot of time doing the analysis, really thinking it through, and this is going to be a solid product that you release. But, I've also found that in reality that doesn't always work out that way because, when you create one of of these larger documents, you're doing it in predictive manner.
Meaning, you're assuming that you can figure all the requirements, every little bit and piece, and it's a done sealed document and everyone can fully understand it and go forward with it. But, in reality, it really needs to be adaptive. And that's where things such as change request. I'm sure many of you have felt the pain of going through change requests and resisting change or changing these documents.
So it's always been a challenge with these large documents that are signed, sealed and delivered. And with Agile we found a new medium that has allowed us to be a lot more adaptive to the changing business requirements as business value change, or new ideas merge. We can actually accept them. And Agile facilitates that acceptance of changes, as opposed to, what I've always found with traditional requirements, resist change after sign offs are done.
Yeah I'd agree with all of that and I think the key pieces that I see with it or the key limitations I see of large requirements documents is there's no indication of relative value as with the story, your story about the feature that wasn't developed and that being a good thing, is that if that's in a requirements doc it's automatically going to get worked on, and that sort of non-critical feature can hold up the rest of the more critical features.
Also, we talked about that they become increasing irrelevant over time, that these requirements docks, because they are not updated, they become actually poor indicators of what's actually in production. And there's also not an explicit opportunity to apply learning back into the, you know, into the product development cycle every time.
But I do have just a quick question for you because one of the critiques I hear or concerns that I think a lot of people have in an Agile environment is what about deadlines or what about meeting deadlines because, as you say, these requirements docs do give us an opportunity to be predictive, or they, at least the illusion or indication that we're predictive.
So, to meet the deadlines, these, we usually, when we try to use these documents, we often find that we miss the deadlines anyway because new requirements do come up and we start doing these various change requests. So that pushes out any deadline we set ahead of time. So, now in our Agile methodology, what we do is we look at the true capacity of the team, our true ability to deliver, which is our velocity, and that helps set what we're going to to be releasing and when we're going to be releasing it.
And a lot of this is driven - actually, I'd say it's mainly driven - by the user stories, us estimating the user stories, and us prioritizing the user stories.
Right. Thanks. And I'm just going to throw a couple of quick quotes at you and then we can take some questions and then drill down into the sort of, how, how we're going to write user stories. So the quotes I like, one comes from our Agile fellow at Rally, Jean Tabaka, which is, "A well written story doesn't lie. Requirements do by their sheer volume of content."
And then this is my favorite from Mike Tyson which is, "Everyone has a plan till they get punched in the mouth," and I always think of stories like we can respond to getting punched in the mouth or getting punched in the market, as it is, much, much faster, much, much better.
So, I want to open it up right now.
I'm going to ask, Drew to kind of pull up a couple of questions for us and we'll, we'll pause before we start digging into the actual nuts and bolts of how to write great user stories.
Yeah, we've got a couple of questions coming in that I think are repeating a theme here a little bit. How do you, how do you all typically see teams kind of circulate or get consensus on user stories with the rest of the organization and, you know, probably in particular stake holders or business owners?
Well, I mean, how, you know, I actually it's a great question. Because, how do you write great user stories? You write them collaboratively and you have to come up with collaborative systems, collaborative, you know, meetings, ways for the team to be talking to each other. It's not one individual that writes user stories, it's the team
that develops, writes, decomposes them together over time. Geoff, maybe you can speak to how do you guys do that at Citibank.
Sure. I couldn't agree more with what you said, about the collaboration. It's the entire team coming together so in our sessions, whether we write the user stories within a sprint planning session, or a grooming session, which I think we'll speak more about later.
What we do is we have the whole team there. That means we have the developers, we have the business-slash-product owner. We have the UAT and QA, architecture. Everyone comes together to help define and refine this stories . But an important piece about this is that the team as a whole, especially the product owner, needs to be empowered to create and drive the direction.
Because the problem always is if you have to go and say, I'm sorry I have to bring these stories to a committee, and they have to vote on it, that is going to hinder the whole initiative, and the ability to quickly deliver. So, it's really important to enable the business owner to have the authority to make decisions on, is this a worthwhile user story or not, and what the priority is against it.
Great. I couldn't agree more. As a former product owner, I couldn't agree more that you really do need to empower the product owner to make the up down decisions and at the same time you need to be collaborative. It seems to me like all Agile processes, there's a combination of flexibility and discipline.
I mean, that to me is, agility is essentially the dynamic tension between those two. Do you have another question?
Yeah, maybe we'll take time for one more, and this one is kind of a role team-related one, too. And just for everyone online, we're getting a lot of questions around sizing and estimating and splitting user stories. So, we're going to get into that in just a few minutes. So I'll hold off on those, but we've got some good team related questions here.
And this one really is around, we've seen this a couple times over the last couple webinars, how does the business analyst role change, especially in relation to maintaining a backlog of user stories?
Yeah, it depends on the organization and, Geoff, I'm actually going to throw this out to you. How does the BA role work at or how has it changed in your environment?
Well, it again depends on the team, even within Citi. So we do have BAs on the team and they play various roles. Sometimes the BA is actually the product owner.
At times they actually are partner with the product owner and they are partially the liaison with the product owner and the rest of the team; where the team, instead of approaching the product owner for a lot of daily questions, approaches the BA. But in that scenario, the BA is much more empowered than they are in a traditional waterfall.
So, it varies, but there absolutely is a place and in many times a need for that analyst who is an expert in that area.
Great. Thanks. So now let's move on. We're going to go through some of the nuts and bolts of user stories, just so we all have sort of a baseline of what we're working on here. Now we think of user stories as really having three key components. There's the card, there's the conversation, and there's the confirmation.
Let's start off with the card piece. So the card is really, you want your user story, there we go, your user story to fit on a card and it wants it to encapsulate three things - the who, the what and the why. The role, like who it is we're building something for, what it is they want, what they're trying to accomplish and why they're trying to accomplish that.
And we always think of this as a sort of, this is encapsulated business value. So you've, in language, you've captured an indication of, like, if you were able to provide this capability to somebody that they would be willing to pay for it, essentially. So, it's an encapsulation of business value in language as a who, I want what, so that why.
Now, that's great, but it's somewhat useless unless there's a conversation wrapping around that. Let's talk about the sort of a, let's walk through a conversation. We're going to take this out technology a little bit, so perhaps it's a little more clear. So, as a busy breakfast maker, I wanted the toast to pop up when it's done, so that I can focus on other things while it's cooking.
We can see why this would be valuable, right? We're making some toast, but we're all able to make toast, but the toast popping up when it's done, this is potentially a useful thing to someone who doesn't want their toast to burn or wants to be able to focus on other things. And it also seems like a reasonable request, and here in this next slide we have a very, very handsome - no, this is not me - but a very handsome product owner making this request in conversation to a developer.
So I want the toast to pop up when it's done. The developer comes back and says, well, that's really expensive. The popping up part is easy, that's just a spring. But knowing when the toast is done, it's is going to require an optical sensor, this is a new technology, and this is going to be something that's going to take quite a while to develop.
Now we can see that if we were in a traditional throw it over the wall requirements world, that this developer might have already started working on this rather than having this very crucial conversation. Conversation comes back to the product owner and he's curious, what about all those other toasters out there?
The developer comes back and says well, they don't use a timer, it's a kludge. They use a timer. They don't know when the toast is really done. And the product owner, of course, doesn't want a super toaster, he just wants a regular toaster like everybody else, and here they are happy, having met in the middle at the end. You can see how important this conversation is. There's a lot of information exchange that would have been very challenging to even know if it was needed, you know, before, when we're writing our core requirements document. But because we're using a story based development, encouraging conversation, encouraging this collaborative way of doing things, that we're actually building in a lot more detail, and a lot, and saving ourselves quite a bit of work.
Now, this drives us to the third "C," which is confirmation. And this is how will we know when we're done? How will we know when we're actually complete with this particular feature? And here we are going to go into technology. I'm going to share this particular story, which as a traveler, I want to be able to cancel the reservation so that I'm not charged if my plans change.
So this would be like a traveler's website, and it seems very reasonable. But how would we know when this is actually done? What could be testable? What could we actually test for? And this is what we, where we capture things and what we call acceptance criteria. So the email confirmation is sent to the primary email address, a 10% fee is charged to the account, the hotel is notified of the cancellations, the hotel is removed from the itinerary immediately, so.
Now what we have is an encapsulated business value in the card, in the conversation we've elaborated and so we created a shared understanding, and now here in the acceptance criteria we've created a series of sort of up down testable scenarios, so we know when we're actually finished and when we're actually done.
Geoff, is there anything you wanted to add to this?
What you just described here is an extremely important piece of our whole process. So, when we create user stories, we don't just stop at the user story and say, "All right, here you go team, go build it." There are two other, the two other components are the acceptance criteria and then the detailed task.
So, building out, what is the acceptable - how do we know when we're actually done and created at the end of an iteration potentially shippable software is important guideline and piece of knowledge for every one on the team. Because otherwise one could fairly say a user story doesn't provide enough information. That information starts surfacing for us at the acceptance criteria level and then directly built off of the acceptance criteria are the detailed tasks or, as some people call them, engineering tasks. And those engineering tasks end up being what the team builds against.
Yeah . Yeah, and you can see sort of how each of these pieces of acceptance criteria then break down into the tasks, right. So, that's great and so I want to actually show kind of continuing with our theme of decomposition, which is not a very attractive word for it, perhaps, but it is what we do. We do take large things and make them in to smaller things.
I want to go back to our sort of our breakfast scenario here and so here we might have a theme which is a big you know, like, as a busy person, as a busy professional I want to eat breakfast, you know, so I can be nourished for my day. That might be our theme, and this may break down into three, what we call epics, we could also call these, they could be potentially product lines, they could be potentially features, it depends upon the organization but, we would have coffee, toast, and juice being the three things that breakfast could break into.
And it could potentially break into more, obviously. And in each of these things, in order to accomplish them, are going to break into stories. Now, these epics might be composed into other epics because the story is sort of the developable piece, that small enough chunk that we can use, that we can actually pull into an iteration.
And so we might have to go through, there might be a little more of a gradient. These show really clean lines, and I don't want to kind of fool you. There actually is often a gradient. Epics decompose into epics, which even decompose into more epics before we can break it down to the story level. It's a bit of an art here.
We also, I also just want to show you that we could draw a line around these and say, "Well, what's our minimum viable product for release within this?" And it could be that coffee, we only need two of our stories. We don't need the third, you know, like, espresso story. We only need the basic coffee story.
And juice, we don't need the fresh squeezed story, we only need the out of the jar story. Something like that. But we get a sense of sort of by prioritizing these in terms of business value, we can then begin to draw these circles around it and say, "Well, what is the minimum viable product that we really want to release with?" and actually, Geoff, do you have anything to add, or shall we just go straight to some questions?
Just one other thing to add is about how we, actually, on my teams, we break down the stories. So, everything is in the context of the product vision. So what is the vision we're trying to achieve? And then we start making user stories. Now, a lot of times these user stories are quite large. As we saw in the previous example, they're massive.
It might be something that could encompass 10 people for three months to do. But that's okay. We actually want that. Because by taking the bigger picture, we can break it down to get to the detailed level and user stories that we can complete within a sprint. And just one other point about what we do with, how many do we have in a sprint, etc.
We typically have sprints, or iterations, that are two weeks long. I prefer to have about four to eight stories. People do various ones. They do one to two, they could do sixteen, twenty. It's really up to the team and organization. I like the four to eight because it's just enough for the team to have ones they can start checking off and accomplish.
So if they can only get up to six or seven, then they still did six or seven out of the eight. As opposed to if you had one or two...that means if you don't do one, you only did fifty percent of the ones you committed to. If you did none, if you have only one, you did zero. So, it 's a nice size for us to say for a two week iteration, let's break it down to a level so the team can commit to four to six stories.
Right. And with that, I think we can take a few minutes of questions before going to a demo about how this works in the real world and the real application.
Yeah, let's take a couple here. A really good kind of process related question. When are user stories put together? Do you do that before the project gets started or do you do it right there after in your first sprint planning meeting? How do you guys typically see that play out in an Agile team?
Well, I love to work with stories and story cards before a project gets started to get a sense of what the minimum set is but then you don't want to do too much elaboration because you're just trying to get enough to get going and get a sense of what the highest priority things are to work on. Geoff, do you have some examples from Citibank or how you guys do things there?
Yes. I think you hit the nail in the head where you don't want to walk in your first sprint planning session, brand new team, with nothing. You want to prep it with some user stories especially get the product vision and these stories can be epic size, but that's a great starting place. Now for the stories, you're going to have new stories throughout the life cycle.
It goes back to, can you think of everything beforehand? If you can and you can get it down to the most minute detail, at the beginning then go for the BRD but that typically doesn't happen, so expect and that's what we always do. Every sprint planning, every grooming session, we think of new items, new business focus, new value refine them and change the stories so it's continuous emergent process throughout.
Great, that is perfect, couldn't have said it better myself. Do we have another question?
Yeah let's do one more, it might be a good lead in into some of the stuff Greg's going to demo in a little bit. We have a question I've seen a couple times,when we think about how Agile focuses on features around business value and how those kind of boil up to maybe a road map level and then obviously how would you guys generally define business value? What are the components of that?
What is a business value? Well I let my customer define it for one thing you know, are people buying what your selling and I think one of the benefits of going against sort of a continuous integration, an integrative environment where the story based on what it lends itself to is that you get stuff out there into the market very fast and you just test it find out. You know, you kind of let the market tell you what it's doing. But, of course, business value is also, part going back to the conversation with the delivery team. It's always going to be, we 're going to weigh value that we're going to get against the cost of actually getting it and so the prioritization of something is not something that I can do as a product owner in isolation. I need to be in conversation with the development team to understand how expensive it is, how difficult it is, and what the implications are for the rest of our application.
Not just you know, sort of saying, this is valuable development. Geoff did you have anything you want to add to that?
Sure, I think that's a really good question, because it's, I'm not sure if you ever heard of the book "Zen and the Art of Motorcycle Maintenance" that deals with the whole question of what is value and what is quality, but it needs to be defined by the team as a whole, and especially it's guided mainly by the product owner.
So, we have business value from everything from obvious. Let's add on this new feature for an external client or an internal client, let's fix a bug that's been a real pain so it has a lot more business value than new features, to this is something that's promoting the team within the larger company so that also has different business value.
But I just have one comment on, during the prioritization, the business value is the primary driver for us, but that's not the only siloed prioritization. It's taken as a whole, where its business value helps drive what goes to the top, but considerations around dependencies, technical feasibility, the time - all those planned and the team gives the input about this information to the product owner.
Now I will give a little example. You might have something, well this new feature that you have adding on, say, be able to submit new papers or submit new publications from the client, extremely high business value, but it's an epic and it will take about two months to build for the team of course to break it down.
This other feature - let's say adding on a little button - it's a lot easier and we can do it in a couple of days but it's less a business value.
Well, we might as a team decide, even though this is less business value, it can be done right away, and it's quicker to market, so maybe even increasing the business value. Let's do that small button first. So, it's always a negotiation and a educated decision process.
Okay great. And with that, I want to hand things off to one of our talented technical account people, Craig, show us sort of how this might work in the real world.
Yes, thank you for that great lead in Jeff. That's exactly what we're going to talk about or what I'm going to demonstrate now. We all know that user stories provide great business value, right? And that's really the key concept of a user story. But I want to show in some of Jeff's examples how he talked about how they worked at Citibank, scaling a user's story beyond just a piece of work that is developed or a piece of value that's developed in a single iteration but also scaling that up to what it means to the business.
So, let's pause just a second, while I kick off the product demonstration. I'm going to show us really three key areas, kind of what Jeff talked about earlier, and that is prioritizing those high level business objectives on the road map. So we can easily see what we have planned for next 4 quarters. I want to show how business objective, in this case themes, are broken down into user stories that will be worked on in a two week period, either by a single team or a cross team.
And then, I also want to show how that status of that user story can be reflected back to signal the business in terms of what the next priorities are that we should work on. So we can easily we see by our road map view here, that the individual themes are planned into quarters, so much like Geoff might plan their themes.
We can also see that we have on the left the road map column that shows the themes that have not yet been planned. So, we're looking at our consumer site product line and maybe in this scenario we have a theme, new consumer portal and maybe one or our chief competitors has just released a new consumer portal that has the utmost and extreme ability to be customized.
So a consumer portal that can be customized as well as some security features.
So we want to increase the urgency of our features in our products. So we're going to go ahead and move these features like customize both consumer portal in the Q2 and then you'll see strong password log in the Q3. So we're going to increase the urgency of the features that we're going to work on.
Well, after we've planned these end of the quarters, let's spin down into the Rally application and take a closer look at the work. So from the Rally applicatio, on the User Stories page, we can see that our theme, New Consumer Portal, shows up. And we have two features planned. The feature that we'll talk about is the customizable consumer portal, it's the one we want to work on in Q2.
So, from this theme we've broken down three user stories that, as Geoff mentioned, can span releases, iterations, and might even span multiple Agile teams. One of the key benefits of using a tool like Rally is now we can aggregate the work that we're working on so that we can see a nice roll up of information back up to the theme level.
Let's spin down and take a closer view of one of the user stories, Add Dashboard Panels. This user's story is currently being worked in the Iteration 6. So I'll navigate to the Iteration status page for the shopping team. We can easily see that there are five days remaining for the shopping team in this iteration. Our user story, Add Dashboard Panels, is the highest priority for this team to work on in this iteration, it's been decomposed and the team has told us that it'll take 3 tasks to complete the work. Let's go ahead and finish the last task, which is a code review and once we've completed that work, the user story will signal to the product owner that the work has been completed.
We 're going to go ahead and take a closer look at the user story. As a product owner, we may want to see what did we originally describe for intents and what's the acceptance criteria on this user story? If the product owner finds it suitable, we'll go ahead and accept the user story. And the team will receive credit for five points of business value achieved by completing this user story.
Now let's go ahead and spin back back to our roadmap view and see how Add Dashboard Panels has affected the key feature that we're working on. The feature, Customizable Consumer Portal is in Q2. So we'll take a closer look at Q2 and we can easily see that by completing the one user story, we've completed 45 percent of our key feature.
So from this, we looked at planning our themes and reprioritizing our themes on a road map. We spun down and looked at how teams can work on user stories in an iteration and then we took another view and looked back at how that user story signaled the business and reflected back onto the road map.
Great . Thanks a lot, Craig .
Let me get back to My Views so that I can see what's going on here. So, as we can see, we've talked a lot about sort of refining stories and decomposing stories. And so now I'd love to introduce you to sort of a framework actually that Geoff and I talked about ahead of time, but it's a framework called DEEP comes to us from Mike Cohen.
And as you can guess by the all caps, it's an acronym, D-E-E-P. The first D, and again, this is a way of thinking about our stories as we refine them and as we get more detail out of them. And also we're going to talk about how we decompose stories, how we take bigger stories and break them into smaller stories.
That's what we're gonna finish off this webinar with. So DEEP is detailed appropriately. And Geoff, why don't you take it away?
Sure. So this concept for us is very important. The DEEP and the first d of the detailed appropriate means that we take each story and we put in as much definition as it needs. So what we mean by that is, if something is an epic, something that is at the bottom of our priority list, where epics typically are,
we don't put as much detail around. We don't spend the time because the different notions, thoughts, ideas aren't there yet and we shouldn't spend the time on it yet to go into that level of detail. As we get closer, increase the priority of various items, and they go up on the product backlog in priority, that's when we increase the level of detail and our level of detail could mean refining the user story, being more clear about it, breaking up the user story into multiple ones.
We even sometimes combine together, they're too detailed, and we pull them back up into a single user story and then taking those user stories and decomposing them into the acceptance criteria and in the detailed tasks. So, that's a very important concept for us to always try to not go in either direction too detailed or not detailed enough and we're guided by where it is in the priority and is it upcoming for us to actually do within a sprint.
Yes. My favorite answer when people ask how much detail or how much acceptance criteria do we need to have in our user stories. I always say as much as necessary, and as little as possible. Which I know is sort of a dodging the answer and yet, it is really is true. And I think, teams and organizations need to figure out, you know, how much detail is enough to make sure that the right thing is being built, but not overwhelm your, your sort of extrapolation process early on because you can burn up a lot of time detailing things that you're never going to build.
And one of the things that sort of illustrates this is that in this object, the spike here is our product backlog. As things rise in priority, they should also rise in detail. So, in other words, if there's something way down at the bottom which is low priority, we really don't want to have too much detail about, because we will spend some valuable time that we could have spent working on other things, detailing out what that might be.
But that said, we want to have enough detail there, when we are ready to work on something, is sort of this telescoping process. The other thing that might not be exactly clear from this is that, as we detail something out, we are also able to pull detail out and deprioritize certain aspects of that, certain details of a larger epic. You know, certain of those user stories that don't fit our minimum viable product, we could actually pull those out so some of that detail actually could then get deprioritized as well so it's a little hard to draw so we kept it kind of simple here.
And then, so we're, I'm sorry, we're still going to go deep here the detailed appropriately, the next would be estimated. Geoff, won't you talk to us about what's estimation and what's that about.
So, this is another important concept that we practice. And this is estimating the stories. So, there's many reasons why we do this. One, we get a sense of how big the stories are. We use story points against it. So we have a product backlog. We have it prioritized, but part of the prioritization we do against it is having it estimated first.
So we figure out in story points how big, relatively, is this user story. And that helps us to figure out where to go on the priority list.
Should we break it up? Because the team is estimating as those who are familiar with it, 13 or 20 size. It 's probably a good candidate to be broken up. Is it maybe too small? It's a 1 or 0, we can now combine it together.
Also it gives a great sense when you estimate the whole backlog, as a manager, to figure out if I have an upcoming release on this and this date. What can I accomplish based on my capacity and past velocity? So I can take an estimated backlog and say, "Well , I have another two sprints left. I want to have a release then.
I have a capacity of, you know, velocity past velocity of 30 points, so obviously I can do 60 points worth of work."
And that will allow you to estimate what you can do, when. So it's a very important point for both a prioritization and also management for release scheduling.
Absolutely, yes. Like I said before you know, value is a, you have to indicate cost as well as the value received from a feature and so estimation is really where, it's how the product owner gets to know how much something's going to cost him or her.
So, the next E is emergent. Talk about that a little bit, Geoff?
Yeah, so I mentioned before emergence. That really goes a theme I've found throughout Agile and what our team really practices. Where we're trying to not be predictive but being adaptive where new ideas, new thoughts come out. And that goes into an epic, where we're not afraid of building out epics, and we don't want to spend as detailed, probably too much time against them, because new thoughts, new items will emerge.
And also goes with, can we think of everything ahead of time? No. That's why the product backlog is going to grow and change over time. So new ideas we've refined will be emerged and we try to accept that as Agile as a whole does, any of those changes. Now, just a, a thought on that, because you might say, well, you know, some merging, things are changing, that could cause problems to the team.
Every two weeks, we commit to doing x number of user stories and that becomes our sprint backlog and during that time, we don't change what has been committed to. It's only during our planning session that we allow new items, new priorities to emerge for us and then we can commit to those.
Great . And then the last, the P is prioritize which we discussed quite a bit. Do you have any parting shots on prioritization?
Nope. It 's just, we try to do also prioritization during grooming session or grooming the backlog which is prior to our, every two week planning session. So, we do is we go through it again, do other estimates, create new ones and actually try to prioritization to get it prepared and ready for the upcoming planning session.
Yeah, absolutely. And we talked about that we, we, we have several sort of fixed kinds of meetings. You know, our daily stand up, our sprint planning, our retrospectives, our demos, that kind of thing, within a traditional Scrum or Agile process , but the back log grooming is one that I find that each team again has to tune for themselves and again do as much as necessary and as little as possible in order to be that sort of vision and enough detail, maybe two or three sprints ahead in their backlogs is the rule of thumb that I usually use, in terms of prioritization.
And of course that can change, though, you know sprint to sprint. A couple more things I wanted to just kind of introduce you to really quick for our participants here, these R and R in the packets that you've received. But, and then I wanted to actually go to questions. I want to try to save as much time as I can for questions, because we have a lot of great questions coming through.
This is another framework, it comes from Bill Wake. It's called Invest. Good stories are independent, negotiable, valuable, estimable, sized appropriately, and testable. I think those kind of speak for themselves and there is a lot of great writing about it out there. I think we've introduced enough framework so I'm going to gloss over this slide for now, just so we can get some of your more detailed questions that are coming up.
Also in your packet you'll find that you have 20 ways to split user stories, and again this also comes from Bill Wake. But these are the sort of different tests or different kind of heuristics you can use when are thinking about, when you have a big story that you know has to be broken up, you know, how are you going to break it up?
And what might you do, how might you think about this in a way, so you can break it down into that developable piece, that piece that can be developed over. Developable is challenging word, but they can be developed over a two week period.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form