Agile User Stories
ฝัง
- เผยแพร่เมื่อ 12 มิ.ย. 2024
- Learn how to write good user stories for Agile teams. If you'd like a free book on this topic, please see below...
I've published a book called "Starting Agile" that is designed to help you start your team's Agile journey out right. You can buy a copy from Amazon, but I'm giving free copies away to my subscribers from TH-cam. You can signup for a copy at this link:
www.xeric.net/#starting-agile - วิทยาศาสตร์และเทคโนโลยี
Sharing your knowledge in such a profound, friendly AND easy way is pure magic. You're amazing. Thank you very much.
I share the same thoughts on this. Thank you Mark.
This clearly and briefly explains what user stories do and why it makes sense to use them!
Another great video from Mark! Again, as a non-techie, I can visualize the usefulness of this technique. I'm currently taking a gap year to study supply chain and database design. Now, I have a wide variety of options to include or not in my learning path. This sometimes leads to confusion or replication/duplicity of work.
Now, I have a fair idea of who my potential customers would be (additionally, I can do a little research on the net/web to identify potential types of customers). I have, in an earlier avatar, worked on rural development projects, where it's quite common to put yourself in the user's/beneficiary's shoes and assess/evaluate from their viewpoint. This limits to a large exte nt money and time wastage.
Here, you give a framework for seeing things from the user's viewpoint and clear examples to grasp the essence of the concept. So, using this framework, I can work out what are the various things/solutions a potential user/customer/client would want, and rework my learning pathway towards that. This would, in addition, ensure that I do have gainful employment after all the studying is over. After all, what's the use of studying if what you learn does not match market requirements!
So, thanks a lot for this great video.
I really appreciate this video. I work as an IT BA in local govt and was struck esp by the part where the user felt "in the dark". So easy on a project for tech to get caught in the weeds when sight is lost on the original goal.
I am just starting out in the world of User Stories and your video's help tremendously. Thanks so much!
Thank you, this video helped me understand user stories. Well explained.
You hit a lot of points very simply. The 7 minutes literally sped by. Very nice.
Glad to hear it! Thanks for taking the time to comment.
Feedback: Again, underrated video, underrated channel! Thank you for the work!!
So glad you found it useful! I do live lunch and learns each Tuesday at noon central time that you might be interested in as well: events.xeric.net/
@@MarkShead Thank you for the information, but unfortunately that only works for certain time zones :D But if I happen to get closer, I'll take a peak :)
Sir Mark this is truely out of this world, You are amazing
Simply excellent. Really appreciate the amount of work put for this. Cheers !!!
Thank you for taking the time to comment. I appreciate your encouragement.
This is really great. The best tutorials out there for this particular niche!
Glad you think so!
Awesome story about user stories. Thanks Mark.
Great content, and so is the style of delivery! Awesome stuff! Loving your videos on Agile.
What a great explanation, thanks!!
Mark: Hi I'm Mark!
Tommy Wiseau: Oh hi Mark!
i did nAHT hit her
@@shinygem0411 its bullshit, i dyd nawt!
Gracias por compartir el conocimiento! ganaste un nuevo seguidor!
The animations are GOLD!! Thanks for sharing your knowledge and using your skills to help others.
pppppooooooooooppppppppppp
Which software for animation?
Classic examples and good animation! Cheers Mark :)
This is amazing. Thank you for the explanation!
Great Job! easy to understand.
Nice summary. Thank you for posting it.
this was beautifully explained, thank you!
Sweet! Thanks Mark
Great video. It explained clearly the concept of user stories in Agile projects. Thank you
very good demo thanks
Love your work and will love to collaborate. Its been very useful for onboarding newbies and reiterating standards for the old blocks.
Super helpful, thanks!
This is everything I needed thanks a lot
Brilliant and simple explanation.
Excellent! Not many people bother to go back to basics to really understand it.
I find this is a big problem with a lot of Agile teams. They want to move on to advanced stuff without getting the basics right...basics like frequently delivering working increments to the customer.
Excellent explanation!
It is a perfect lesson. Thank you for information. I really appreciate what you have done.
this is very help full and amazing, plz make a test case writing example video
Thanks for this video tutorial.
Very good presentation. Explanations are planned well and accurately presented.
Awesome video! Thank you. I create a lot of how to videos. What did you use for the animation and to sync his mouth movements to the script? Love it!
Thank you for taking the time to comment. We used a tool called Go Animate. It handles the syncing automatically.
excellent..
very helpful and very informative thank u
User's stories is a process perspective. How do you deal with the information perspective? This way of working gives the end-user to be the "analyst" (is that his job? can they do that? do they know what software and computers can and can't do?), since (s)he defines what user stories he wants. Developing the users story will meet the demand (what the end-user wants). But the assumption is made by doing so, business value is created. How do we deal with enterprise-wide coherence, enterprise-wide optimisation, information sharing, reuse or with innovation? How do we identify and exploit all other ways by which IT can create value and even drive business? This is demand-driven, thus reactive, thus there is always lag. .. just a quick critical note (not about the video, but about the technique itself). But thanks for the clear explanation given in the video.
> How do we deal with enterprise-wide coherence, enterprise-wide optimisation, information sharing, reuse or with innovation? How do we identify and exploit all other ways by which IT can create value and even drive business?
In many cases organizations aren't struggling just with getting working software done and into production on a reasonable schedule. Enterprise-wide optimization sounds nice, but if it takes you 6 weeks just to get a single change into production, you have a lot of low hanging fruit to pick first.
However, my general answer to how to handle all those things is basically to make sure that change is not expensive. A significant part of that is how you handle testing. I find that teams that make a real investment in BDD and TDD have the ability to make changes and get them to production quickly and this gives them the ability to create value in ways that are simply not possible using approaches that can't deliver small changes quickly.
@@MarkShead Thanks for your response. Best for 2019.
Sad enough users impose their view to the developers, because this is the way projects work. In my oppinion there should be a dialog between users and developers, the user stories (or use cases) should be defined or redefined with the advice of a tecnician who can suggest better ways to do things. For example: a user can request a story to search a book in a library catalog, his idea is to use fields like isbn, title, author, theme, publishing year ... but a technician can suggest a simpler interface with just one field where the user writes whatever criteria he wants and the system knows what type of search really is, like web browsers do.
Amazing video, explained so much in a small video. Thank you and I have subscribed.
Thanks! I really appreciate your comment.
Jepsen yeah homes
I've been using agile aproaches since Extreme Programming, long ago. Lately I've been involved in projects with younger folks and I noticed there are a lots of gaps of what "agile" means to me and to younger colleges.
Use Cases: What I miss in user stories is the interaction dialog between actors as textual use case descriptions, specially I miss Alistair's Cockburn writing use cases style. Even worse, stories tend to be just task lists, like "we need to add more subscribers using this and that ..."
No graphical language: I haven't seen any of my collegues using simple flowcharts, not to mention UML activity diagrams, state or sequence diagrams, that I find extraordinary useful to clarify ideas and to help to map actions to code.
No architecture definitiion, no patterns: When you know something is going to change, prepare for it, define your classes using patterns like policy, builders, etc ... code shoud be closed for modification but open for extension.
No unit testing: I can not name anything "agile" if it does not includes automatic testing. Changing things it's dangerous, costly. If you change things and do not test all previous behavior you are going to be in trouble.
No documentation: No textual use case definition, just code. No architectural design to know where to extend or where to modify. No examples on how to use some api or microservice.
To sum up: I think what is called Agile nowadays, is just "no method" or chaos as it was before the invention of software engeneering. It makes development, very expensive and error prone. Any of you have had the same feeling?
shut up you talk too much
It's very good animation whit great knowledge. Thanks for your job. .
Vida Rural FT Thanks for letting me know you enjoyed it. I'd love to hear what you think about some of my other Agile videos.
Thanks for sharing - Question where does the Business Rules fit in a User Story or do we document it elsewhere? e.g Business process workflows and Business Rules should be documented in Confluence.
This is incredible! Thanks
Glad to hear it. Thanks for taking the time to comment.
The animations are great is this powtoon u used to make this video ? thx for sharing
GREAT VIDEO!!!!
Great. video
Thank you, Perfectly explained!!
Thank you for the video. I am trying to make the 'mental move' to Agile, and want to ask a silly question. How do you avoid too much re-work with this approach? If I have to build a building but only focus on 1 floor at a time (e.g. one user story), without considering the possible total size of the building (e.g. the DB structure to support the system), I likely may not build a strong enough foundation to support all the floors. Rebuilding a foundation when you are on working on the 10th floor of what ends up becoming a 50 story building may not be trivial. Hope that made sense and thanks for your time with this question.
This is why Agile is a method and not a religion. You do the least amount *needed*, but not less - SOME planning, specification, requirement analysis etc, is quite ok and even necessary.
Enter "Design thinking" - the act of developing the minimum viable product or solution on paper before writing any code. You follow the Agile methodology, creating stories and prioritizing them, but in this case, you also map out the entire customer journey.
You are right. I'll tell you a story I'm a pool player, I play rotation games, the objective of the game is to pocket balls one after another in numerical order, that is from 1 to 2 , 3 , ... to end with 9 or 10, depending if you play nine or ten ball. To be able to do so you have to play "position" that is, after potting, the cue ball has to move to a position where you can pocket your next ball.
If you don't have a plan you can get hooked or with a very difficult shot after your first stroke, so you need some sort of plan, but the game is too complicated, and many things can happen to plan all routes your cue ball is going to travel from ball one to the last for the whole game. What instructors and professional players recomend, is to plan at least three balls ahead. Even following your plan one shoot can end in a different way you planned so you have to rebuild your plan for the next three balls, but at least you haven't wasted your time in plans that were just fantasy.
The moral of the story is: plan what you can anticipate, prepare your code for the next changes you think are going to happen, but do not plan things that you are unsure or that depend on the result of a previous step that the stakeholders have to evaluate. Not planning at all can led you to dead end that will make you "lose the game".
Unit Testing is a must, if you do not run automated tests you are going to screw things up sooner or latter.
This is amazing ,
Very good video, Mark. My only suggestion is to include a re-write of the developer's story from 4:29 . For that scenario, what's an example of a good story?
I'm just learning about stories and that part left me confused. I'll figure it out, I'm sure. 😊
I guess what he's trying to tell, wich is in my practical experience wrong and critical as it prevents the company from scaling is: Create Infrastructure in Stories, but just a bit. Which is really bad as you will miss important topics like: Backups, Load/Performancetesting, Failovers, Documentation... all that stuff which increases stress level where people have to work more then they should or they are paid for. Of course one could buy just expert infrastructure as PaaS/SaaS but that creates a vendor lockin and can ruin your business as well. The reason nobody is talking about that is because of the survivor ship bias and people are only talking about the winner.
Just as an example take Amazon. They just make the Developers to their own customers and then opened the product to the open market after it was quite stable. I think thats a good example that those stories are good stories. Those stories are only bad, when you have that circular dependency. Thats why you should build your business with experienced employees who can imagine the non functional requirements for such a database.
Another example why its not true, that Developerstories are bad is optimizing own work. So if you only describe everything from user perspective you'll never optimize the process of building stuff for the customer. That said I often worked at companies which became slower and slower and finally got outplayed by faster moving companies highly focusing on that part. Means beside of Customer Value the are focusing on Developer Value as well. Now you can only prioritize two kind of Tickets when you can compare the Value of each other. So you have to write them down in a similar way and you have to be able to put numbers on them.
Some companies are trying to bypass this by setting Definitions of Done and #softwarecraftmanship. Setting high Software and Infrastructure Standards which should assure that you don't get slowed down. Unfortunately in reality its hard to maintain those standards and stick to them as sometimes (or mostlikely very often) you are forced to hurry and violate them.
So if there is nobody who focused on that topic they are getting ignored and so the technical dept keeps rising.
I'm not sure whats the best way to tackle that but it is important and there MUST be an implemented process to tackle those topics. Also there should be one Person who tracks them or even better a System which is not allowed to bypass (or at least not allowed to bypass for a specific period of time).
Also a bit offtopic: I'm a huge fan of adding nonfunctional criterias to the stories. Like how long should the user be able to store his data? How much space does he get?
This video does not tell much about refinements and I guess its not the scope, but interested people should search for the 3 Amigo Refinement where those Questions should be answered (and of course asked too).
Awesome video
Superb.
Great Job
MERCI
love the visuals 👌
any on how to gather requirements?
Excellent question. I should probably do a video on that. I would suggest gathering detailed requirements as close to the actual programming process as possible. Use a user story to capture the big idea of the feature then right before you start programming, sit down with a developer, user, and tester and go through exaclty what you are going to build and how it should work. Personally I like to use a BDD process with something like Cucumber to capture the requirements as executable specifications because it lets you turn those discussions into concrete examples that can be executed any time to verify that the examples still work when you make other changes.
Does that help? What other questions should I answer in future videos?
@@MarkShead hey! I am new to BA never worked with IT side just business side.. but now I am transferring to it will be working with IT (qa/dev scrum)
worked as a QA before 3years
I guess new topics use case vs user stories
How does a BRD differ in waterfall vs Agile?
A BRD isn't an Agile concept. That doesn't mean you won't have one on an Agile project, but it is probably coming from the business culture not the Agile culture. In general though, Waterfall assumes that you can define everything in advance and then build it. Agile says that isn't the most efficient way to build software and instead suggests that you focus more on what you can deliver to the user that they can use next. So Agile teams are more likely to have general short user stories to represent functionality and then when they are ready to work on that part, they sit down with the user and figure out how to implement that functionality in a way that is most beneficial to the user with the idea of getting them something they can use in the next few weeks if possible.
Does that help?
@@MarkShead yes it helps makes sense.. one question is user stories and user requirements same?
I believe stories is defining requirements as a user.. etc.
requirement is something like not this, but that is required in a story?
User requirements are what the user requires the software to do. The user doesn't always even know what their requirements are. User stories are one way to try to help concretely represent this abstract idea of the user's requirements for the system. Now a lot of stuff does get called user requirements, but I think it is important to differentiate between the abstract idea of what the user requires (whether they really can articulate it or even know) and the way we try to represent those so we can talk about them an organize them.
You explained why the dev example was a bad story. It would be helpful to show how you would rewrite it. I think I understand, but the example would have solidified my understanding or proven I am still wrong and how to fix it.
Thanks
Good explanation with animations 👌👌👌👌👌... If possible could you please share .. who will write a user stories and use case and with whom?????
Generally the business owner will come up with the first draft of a user story and it is used as a starting point to discuss with the team. Sometimes teams write them together as they figure out how to articulate what will give them the best business value. As some point before you start working on. a story you need to make sure that the business side of things, the developers, and the people responsible for testing and qa all agree that the story is possible, valuable, clear, and small enough to be delivered in a short period of time.
Try it on 1.25 speed. Thank me later.
❤❤❤❤❤❤❤❤
Which animation software man! Awesome work
The software is Vyond.
please can you tell me what application did you use to make this cartoon and animation?
Ash Ganatra GoAnimate
From which software u made animations
Which animation?
did u find it
Hi Mark. I like this video. I link to it in a workshop that I conduct. I do, however, have a question about some of the example stories at the beginning of the video. As "website visitor" and as an "admin user" lock us into a website - am I creating a foregone conclusion that some implementation details (like creating a website) for helping a customer achieve their goals are locked in? "As a website user" indicates that we have already locked in this customer's avenue for keeping up to date on product details. What if there were another way a customer could keep up to date on product details - maybe it's not a website but rather a mobile phone application, and maybe updates aren't email but rather text messages or notification badges? How could these stories be crafted in a way that opens up the possibility for conversations about whether or not we want a website at all? I'd love to hear your feedback on this.
Good point. One aspect of this is that by the time you get to the point where you have a user story, it isn't completely up in the air what the solution will look like. For example, saying that a user wants to be able to reset their password could be done in a number of different ways. It it too constraining to say they will be emailed a reset link? Maybe, but at the same time, delivering a reset password by carrier pigeon probably isn't in the running.
Often times these constraints have to do with what the system already does. For example, if you already have a website and an email list, a story calling out how you want them to work together isn't a completely blank slate. Still I think you are making a very important point that if you are too specific you might miss opportunities to get better collaboration on an even better solution.
Thanks for pointing that out.
Great!
Good point on what to avoid (developer stories instead of user stories) at 4:23
Hi nice video, what software are you using to create these cartoon videos. I have a Project Management channel and would like to utilize these kind of cartoon videos to explain better. Please let me know
We use a tool called Vyond for these. Best of luck!
Slower speed is better. I checked others, but I prefer this.
Thanks. Appreciate the feedback.
Thank you for the effort, though it was a lot of theory and very few real examples.
no, you're wrong, that's visa verse...
@Mark Shead - The part you explained around 6:20 that the developer may have to re-factor code as future stories become clear. Do you know if in relaity that can cause a lot of code re-write? I have been thinking about this for a long time. I would appreciate if you can comment on with your real expertise
Yes. It means you'll be rewriting your code on a regular basis as you discover better ways to do things or you need to expand its capability. The big difference is how painful that is. If I expect to continue to refactor and rewrite my code, I'll do things to make that easier--like investing in tests. That way changes that might take weeks on a traditional project can be done in days or hours simply because I have a fast way to get feedback on whether everything is working correctly.
What has your experience been in rewriting/refactoring code?
Hi Mark, do you have some help to work with backend develop?
Are you looking for help with a software project or are you asking how you can create stories for backend work that a user can't see?
Second option, create stories for backend work that a user can't see.
:) Btw that was fast! thanks
Almost any type of backend work should be doing something for the user. Maybe it isn't something that shows up in the UI, but it should be something that a user can understand as adding value. So think in terms of how you would demonstrate that value. Maybe you are adding a feature that reads a file in a directory and processes it and puts it in a database table, but there isn't anything that user really does to interact with it. You can still write a story about how this provides value to the user and you can still demonstrate that this is working to the user--even if it means you have to place a file in the directory and then show them the table in the database.
Now most of the time, things that have value to a user do have some type of component that a user can see or interact with so start looking for those first. However, if you can't find anything just ask yourself what value is being provided to the user and how you would demonstrate that value to them. If you can't figure out what value it provides to the user, then maybe no one would notice if you didn't do that feature.
Does that help?
Thank you. Do you have anything that helps facilitate this process of breaking feature during a PI planning? Some idea how to break it in smaller slices?
Does this video help? th-cam.com/video/EDT0HMtDwYI/w-d-xo.html
I understand that the user story in the view of a developer seems to much work handle (and that it is hard to show progress to the customer). I also understand that you need to see it from the customer side. However, what are great examples of user stories for this kind or problem. 'write your stories from the user perspective' is a big gap
So one simple example would be to think of a shoe store trying to sell things online. How can you give the company the smallest thing that might be useful and might be demonstratable? A full e-commerce application might be too much, but what about just getting the inventory to show up on line with a number people can call to buy the shoes. Just a single page with the inventory sounds small and developers might even scoff saying it is just a single page. But it is something the customer can use once it is deployed even if it isn't everything they want long term.
@1:51 "keep my ke-count secure"
That is a well explained simplified version of what I was looking for but since i'm a novice, I'd like to start somewhere, i tried to grab the free copy although i'm subscribed but I haven't received my copy after entering my email address. Please help me get the copy.
Did you get the email with the link to LeanPub where you can get it? It sometimes doesn't go out for a few minutes after you sign up.
Any one has formats for user stories. I'm new to this
Just FYI - I noticed a typo, around minute 2, 'susbscribe' should be 'subscribe'...
Otherwise, very helpful content!
Unfortunately, I can't change an existing video, but thanks for letting me know.
You just explained this so easily than the 3 hour video I saw earlier.
Good content, audio quality lacking. I can hear your room echo/reverb and background noise in the narrative. Isolate and dampen, somehow
he keeps his caccount secure....
need to put on 1.25x or 1.50x speed
3:39
Where’s grounded
1.5x speed
swallowing noises are seriously stressing me out, I have to watch another video. Please edit the swallowing sounds out. Not very professional
You must have good ears. :) I couldn't find exactly what you are talking about but there are some sounds where I edited the video to cut out vocal flubs. Thanks for the feedback and I'll see if I can keep it cleaner next time I record audio.
Mark Shead Hi Mark, thanks for the reply. Apologies, I reread my comment and sometimes we can forget it's a human being on the other side of the screen.
It's right at :49. Turn it up and you'll hear it. It's pretty... loud, if you have sensitive ears like me.
What sort of audio equipment do you use when you edit videos? One thing I always use when doing audio recordings is called a noise gate filter. If your recording is below the threshold you set, it will not record any sounds coming through. It's usually used for feedback control, but would help with things like this as well.
Also, by using saturation, and by EQing your voice, you can get a much deeper and easier to listen to voice. I hear a lot of computer fans and stuff in the background as well. Some software tricks can really help with audio production of videos as well.
Thanks. I appreciate your suggestions. I actually tried some other settings on a more recent video. Does this one sound any better? th-cam.com/video/ZZ_vnqvW4DQ/w-d-xo.html
The developer's story was "bad", but you didn't show a "good" version of that story. Nice work in general though.
Thanks