This video is basically just a lecture to help you understand the thought process behind user stories as well as other analysis and design artifacts like epics and features and how all of these work together to help you manage your application development effort.
So you don’t have to watch this to follow along with the story line if you’re not interested in the process of software development but it might help you understand why user stories are so important in agile software development and specifically how they’ll be central to the DevU project itself.
So as you already know Visual Studio Team Services has a plethora of different services to help you manage your application your code and everything so everything from agile requirements management like we’ll do with user … like user stories and then also project management features including reports task assignments issue tracking things like that there’s collaboration features were we’ll be able to add a discussion over just about anything.
There is the code repository which we’ll set up soon, there’s the continuous integration so that we can continually build and deploy our application out to Azure. And then there’s a whole testing suite that’s a whole beast unto itself.
So in this “how do I” style lesson, the “how do I?” will be less: “how do I use my hands to build user stories?” (although we will talk about the format of a user story) but I want to focus on just the agile requirements gathering part.
[00:01:36] And some of the project management features so: “how do I use user stories?”
OK? And whenever we talk about things related to to the agile process I love to point people to this web page.
You can see the link on screen right now, because it has a great large, colorful image in the middle of the page that helps map the thought process and the relationship between these ideas, these entities and the feature in Visual Studio Team Services that supports it.
All right so there’s a couple of quadrants here. There’s the portfolio backlog.
Whenever you see the term backlog that just means it is a list of things that have not yet been started. = So … it could be an epic or a feature we’ll talk about what those are.
You’re already kind of know what the user story is.
So you would add them as in the backlog and then as we drag them into iterations and add into a Kanban board where we can start assigning and tracking then they’re no longer in a pool in a backlog per se, they’re active, OK? So there’s this portfolio backlog where you see a lot of the color in the boxes are but then there’s also the test portion of Visual Studio Team Services, the feedback portion and the code review and all of these will get some attention throughout the lifespan of this project.
But we’re going to focus here … keep this hierarchy in your mind Epic, Feature, User Story and then Task.
Furthermore there are some other things like Bugs and … you know, we’ll get to those later but they’re just basically types of Tasks. OK. So let’s get back into how does this really help us here.
First of all let’s talk about Epics at that highest level.
An Epic is basically an initiative in an organization. Something so big that it will transcend individual iterations and software releases. So we might have three or four iterations that go into a release. We released the software to users and then we might have three or four more iterations of development, bug fixes, feature enhancements and then do another release and then a couple more iterations of development, fixes, blah blah blah blah. And then another release. But an Epic spans across individual releases and it’s something that is kind of at the highest level view — the direction we want to take our — our software.
And it’s usually seen from, you know, a large enterprise, a senior management or even board of directors perspective. It’s very strategic in nature.
So most small companies don’t need this.
I don’t need it. It’s just another layer of — of management of — of organization. It just … I don’t need it. OK?
And in fact if you go to your dashboard and you take a look at your Backlogs you’ll see things like Features and Stories. We saw those represented in that image a moment ago but don’t see Epics. Where are Epics? Epics are not even enabled by default in Visual Studio Team Services. To enable them what you do … (See if I can get this right because there always seems to change on me here.)
You go to the Team, you go to Team Settings, and you go to Overview. And hopefully this Work tab will have it … Yes. See we can turn on Epics right here by clicking the check button and then hitting “Save” presumably somewhere but I don’t see the Save button, maybe it just saves it automatically. That’s scary. All right. Go ahead turn that off. There are some other work related settings we can make here. I don’t want to touch anything for the moment. OK. So just want you to see what an Epic is.
And so as you can see from our diagram here. The Epic gives way to individual Features. So if I have a broad range strategic vision for something I want the application to accomplish usually expressed not in technical terms but more in business terms, then individual features will fall out of that. And a feature is basically something that really can’t be easily delivered in a single Sprint / Iteration. (Whatever you want to call it … in a single release) but a can be delivered in a single *software* release. All right so Features are usually associated with Epics if you’re going to use that organizational tool.
So a Feature is what the customer wants. It’s the client’s needs and you write a feature like this little formula you see on screen right now the action you want to take and then the ogic you’re going to take it on. So here’s some examples like managing courses displaying pages authenticating users. Right. So as you know kind of the plan right now is to create this architectural spike the baseline functionality through the content side of things and through some of the simple management side of things here on the dev Debu project everything from creating a coarsen and adding videos to the course to viewing the course information and the videos on the students side.
So I might start with a feature that says managing courses. OK. And you might wonder why I skipped over features and went right to user stories in the previous video. Now honestly I might add the notion of features in an upcoming iteration or sprint but you know honestly I don’t know that they add a whole lot of value. If there was some some need to communicate this to the other executive members of my team or middle management then yeah but it’s just me. It’s two college kids right. Do I need that kind of structure. I don’t need it. I might still include it just for your benefit. But basically once you have your features defined then you start breaking those down into user stories and that’s where we started.
In fact, if you look on the same page and you scroll further down there’s another cool diagram that shows you that typically you don’t start at the Epic or Feature level when you’re in a new project. You usually start by defining User Stories and you define your requirements through the use of User Stories that way and prioritize your Backlog and then later on you let the executives go off and and manage their portfolios of their backlogged items like they take all these usual stores and start putting them in these big buckets like the feature bucket or the bigger bucket — the Epic bucket. Right?
But again we don’t need that. OK. So back to the matter at hand here we want to talk about User Stories.
And so a User Story is something that can be delivered in a single iteration or a single Sprint. A User Story can take many different forms but it’s usually just a simple description of what I call a “happy path”. A “basic course of events” required to accomplish something meaningful in the system. And it usually takes a very specific form and you saw me use that form in the video.
So “As a __” And then you give it the role of the person performing it and that could be that a human person or it could even be some software system, right? But “as a” Role (whatever the Role is) “I want to __” perform some action in the system.
So here’s where you would describe the “happy path” — the course you want to take. “I want to create add edit and delete pages. I want to create a new blog post. I want to update a blog post. I want to …” you know, whatever. “So that __” and then there’s the — the desired end result which gives justification why this is actually needed. OK?
And here’s a little cheat sheet I’m just going to pop on screen right now. “So as a blank I want to blank so that I can blank.” OK so it’s got Madlibs, Right?
And so I’m going to call this the Actor / Action / Rationale. So “As an actor I want to take some action so that I can …” and here’s the rationale why I want to do that.
So the thing about User Stories is you never create just one even around a single idea. In our first Sprint — in our first iteration that we’re working on here I’ve been very generic because we’re in that “primordial soup” period of time in the project. But I’ll wind up coming back and getting more specific as I see what the developers built, what I built, and as I get closer to my vision, I’ll be more specific with offshoots of User Stories so exceptional cases, optional paths. So I’ll create more of those as we get closer to starting the second Sprint — the second iteration. All right.
So the Actor / Action / Rationale sentence is really the main focus of a User Story and Visual Studio Team Services.
There’s also some meta-data that you can add as well and I glossed over some of these. Let’s get back to one of these guys here. Go back to the DevU and take a look at our. Whoops, whoops, whoops. We’re not in the right spot.
There we go. OK.
So here we’re looking at our Kanban board in our current spike. And you can see that I kind of recorded this video after I’d done some work here so you can ignore some of this and how this all will come to play. But I’ve already added some of my User Stories to a specific iteration. You see I’ve already assigned somebody to be responsible for this and I haven’t, maybe, adjusted the state on this particular one but there’s others that are currently active as I record this. OK. Particularly the card — the biggest portion of this card is the description. So this is: “As a role I want to …” And then here’s the Action. And then finally the justification — the rationale “… so that I can blah blah blah”. All right? And there’s all this meta-data there are there — are Areas there’s, you know, which Iteration does this belong to? There’s things like Reason and State.
We’ll get to Story Points. Those will actually be useful. But Classification, and whether it’s Business or Architectural Value Area. All right. And then the Acceptance Criteria there’s all this meta-data that you see associated with with a User Story. And these are optional elements that I would say either are planning or classification style information now. The meta-data is usually used in larger projects by people in roles that have a management function, whether at a project, product or even executive management position. It helps them plan and organize the individual tasks; who does what and when will it get delivered?
And I think I’ve already talked about Story Points at least in some small way. They are arbitrary measures of effort that are required to implement a User Story. So, in simple terms, there is a number that tells the team how hard a story is to implement. So “hard” could be related to complexity. It could be really related to things we just don’t know. It might be related to the amount of effort even though it’s not complex, there’s a lot of effort that goes into it. Whatever the case might be, we can justify that by adding Story Points, and that will help us to decide whether we can fit a given User Story into a Sprint, into an iteration. Let’s see there are other things too.
And some of these are configurable like you can add or remove them. For example, there’s Priority and there’s Risk.
So, Priority is usually used by a larger organization as guidance to what should be tackled first from management’s perspective. And so you have, usually, three numbers here one — or actually one through four — sorry. And basically they should represent things like 1 – product can’t ship without a successful resolution of the work item. It should be addressed as soon as possible. Priority 2 means the product can’t ship without successful resolution of the work item but it doesn’t need to be addressed immediately. 3 The resolution of the work item is optional and based on resources time and Risk. And number four it’s just I guess it has no priority whatsoever in the system. Alright?
Then you can see the Risk — there is a high, medium and low Risk options that are automatically available. And so this is, again, another subjective rating that — that of the relative uncertainty around a given User Story. So a “one” would be high risk. “Three” would be low risk.
We saw the the Value Area before, whether it’s valuable to Business or Architectural parts of the business, I guess you can say.
Here again, kind of difficult to understand under what scenarios that you might you might actually use this or need this. It’s really up to individual organizations to figure that out for themselves. I think some things like the Risk and the Value, they demonstrate the mindset of Microsoft as they go went out to build Visual Studio Team Services to make it very flexible. It doesn’t enforce a very specific management style. You can use these anyway you want to use them. I think many of the “flags”, the little meta-data here that I call them are very subjective. I mean what is a “high risk task” versus a “low risk task”? Do you — what do you do with it? If it’s high risk do you put your best men on it? Do you have a meeting about it to clarify it? Do you tackle it first or do you tackle it last? So it really depends on your company your situation how you want to use these tools and what actions come out of them. So I see this as more of a — as flags and additional information that the management team can use to mitigate their risk during the project management — or I’m sorry the project life cycle.
All right so Epics and Features and User Stories are artifacts that you typically create during the analysis and design phase of the project lifecycle. When I use the term “artifact” you might not be familiar with that from a software developer perspective. It’s usually a term that means: “at this point in time this is how I understand the system that will be built or the problem that we’re going to address”. OK, so that’s what an artifact is.
Almost immediately after you after you document it, it becomes an artifact like “ancient” and maybe out of date. So that’s why I think the term “artifact” fits here. It may not be the current thinking. It’s just a documentation of how we thought or understood it at a certain point in time.
So I might look at these artifacts as I go throughout the development process and I might use them as reference but ultimately I have to consider them as I design ideas that have evolved over time and may or may not be relevant any longer. So just take them with a grain of salt. And then you should update them as you have the opportunity.
So in addition to being analysis and design artifacts the things like Epic, Features and User Stories are organization tools like I spoke about them earlier.
They’ll also be important as we try to understand the amount of progress that we’re making on the project and ultimately they’ll be used as criteria for User Acceptance Testing. We’ll come back to that later. All right.
So there’s more detail about Epics and Features in my course “Thinking Like an Object-Oriented Programmer”, specifically lesson number 24 entitled “Understanding the Agile Analysis and Design Process using Visual Studio Team Services”, if you’re interested in that great course. I think it’s retail price is $20. You get it with a lifetime or a one year membership to DevU as well. So, let’s continue on. Sorry about the plug.
One of the first things that we’re going to do with the User Story is assign it to a developer to go off and figure out what to do with it and use as a guide whenever performing the — what I call “implementation based analysis and design”. So there’s like “upfront analysis and design”, but then once the developer gets it in his hands there’s more “implementation based development and — or –“analysis and design work” that needs to happen.
So once a User Story is assigned to a developer the real process of analysis and design can begin at least from an implementation perspective. And so, a User Story should then produce Tasks. And a Task — sometimes referred to as a — Work Item — is a granular task. It’s usually either code or some set up or some activity that will produce code or or help to produce the end result.
And it usually can be achieved by a single developer and be — and be used towards the completion of the larger User Story as a whole. All right, so, Tasks — also just like User Stories — they have meta-data. So here you can see individual tasks. For example, “managing payments”, here I’ve got a Task that I called “research integration with strip” … that should be “stripe for refunds.”
All right, so I need to go out and do some homework and see what I can do in terms of automating the refund process.
And there are some of the same sorts of things like Area, Iteration, Reason, there’s a Priority. Here’s an interesting one: Activity. Is this a deployment, designed, development, documentation, requirements or testing activity? All right.
Here’s Level of Effort. The original estimate versus the amount remaining, versus the amount completed. So — here, I’ll go ahead and put two hours in there … that should be that. And that should be zero. Right.
And then it can also tie back to an individual Build the software. Not ready to do anything like that yet.
But you can see there’s meta-data about the Task itself.
And the most important part of that is those meta-data elements that are related to the estimate versus actuals in terms of how much time it will take to actually finish one of these tasks.
And then also I guess the second most important part of what you see on screen is the Discussion area about the Tasks between the team members. It’s in these discussions — as well as discussions around the water cooler or during one of the stand up meetings that the team has every morning — which will ultimately impact the design of the application both at a very grand level and very granular level.
And honestly there will be some decisions that you’re kind of backed into — forced into. They’ll already have been made and that will impact the current task under consideration.
But other decisions might require a couple of developers getting at a white board figuring out how we’re going to approach this because “I’m doing this. You’re doing this and somewhat related to this and we need to be able to talk to each other about it.” Right?
So once the developer sees that User Story has been assigned to him or her then the developer will go off and will try to better understand the requirements. They’ll ask clarifying questions of the customer and then they’ll begin to write the code and / or the unit tests to test that code. And then most of that work, obviously, happens directly in Visual Studio. But the integration as you’ll see is very tight between Visual Studio and Visual Studio Team services. And so what I did was I assigned one of these earlier to Conrad.
I think I’ve changed it now — oh, yeah … here … “Managing Courses and lessons”. You can see that, in a upcoming one of these videos, I will have created this User Story, assigned Conrad. Conrad literally went off and he went on my white board over here and he started figuring things out. And I said “hey, just go over here and look at that go over there and look at that.” So he consulted the customer, the customer said “hey this I want to look like this. I wanted to act like this. I want it to do this.” And he started thinking about the — the domain model and ultimately then the entity model, database model that it would take to implement those particular requirements that I’m verbalizing to him. Now he didn’t document those. We probably should do that at some point. But again trying to be agile.
So once he’s written the Tasks and put in some hour estimates then management (me) can decide “hey, how much can we fit into this iteration? And maybe I should assign one or two these tasks somebody else because it looks like is going to be more work than we anticipated.” Whatever the case might be.
But ultimately he’s going to attack each one of these Tasks. And once he’s written the code and he feels like it satisfies the User Story that he’ll associate those changes in his code to the particular work item. He’ll check in the code. He’ll update meta-data about any of the individual tasks — like how long it took and how much work is remaining.
And then he’ll ask for a Code Review by submitting a Pull Request and you’ll see us do that whole exercise later on day 2 and throughout the rest of this project.
The User Story pops back up during the Code Review. And those who are reviewing the code during the Code Review of the Pull Request will — will take a look at the code that’s been submitted and will look at the User Story and the tasks and then will kind of try to determine if the code that’s been written will satisfy that User Story.
There are obviously other things to consider during a code review of a more technical nature. Things like style and — and whether the code is going to be performant or not. But the User Story will drive the review from the code — from the business need perspective and we want to make sure that it satisfies that business need before we are allowed to go through the system.
So, finally, then, near the end of a Sprint near — the end of an iteration, or near to the end of a milestone like a Build, like a release, the User Story will be used by end users — the customer for User Acceptance Testing. And User Acceptance Testing is the opportunity for the customer or the end user to sign off and say this is exactly what we needed or reject it and say this is not what we needed at all. We clearly didn’t communicate well about this.
And so as you can see here in the User Story — in the meta data –there is an Acceptance Criteria. And here you list out the sorts of things that may not be adequately described in the User Story itself but will be crucial to accepting the — accepting the software from the customer’s perspective.
All right and you want to make that as detailed as possible. There is obviously ways to add images and other documentation,bullets … I mean you can do as much as you want to do in here and then have discussions about it. All right.
All right, so testing — whether it’s manual or automated, whether it’s at a unit testing level or at the very end at the User Acceptance level — the integration testing. It’s a whole other beast in Visual Studio Team Services, and I’m going to be completely honest with you here. I need to study up on a little bit more before I’m ready to do any presentation about it so I want to stay stay kind of at arm’s length from that topic matter until we get closer and I kind of formulate some thoughts around how we were able to use it in our project. But before it’s all over I’m going to create Test Plans and Suites, both manual and automatic, and we will rely on User Stories for that part of the process as well.
But again everything from analysis and design all the way through user acceptance testing — it all centers around the User Story. So you might be inclined to just create the requirements in your head or in a Notepad document, but using a User Story approach, using the tools and Visual Studio Team Services you will get some benefit from that, even on a three man project.
You might think that it’s a little too formal for a small project. But I’m so going to use them for this project and hopefully they’ll be worth their while and the investment in time and effort that it’s going to take because I want you to learn. I want me to learn. I want these guys to learn who are working on this project and I still think that there’s going to be some some value here for us as we just continue to try to stay organized and work our way through this project. OK.
So that’s all I wanted to say about User Stories. It’s all I know. You know as much as I do now about User Stories so go off and make some User Stories of your own. OK.
All right so we’ll pick it back up in the next lesson. We’ll see you there. Thanks