Sharing your knowledge in such a profound, friendly AND easy way is pure magic. You're amazing. Thank you very much.
@kelechindukwe32132 жыл бұрын
I share the same thoughts on this. Thank you Mark.
@ralfrolfen5504 Жыл бұрын
Feedback: Again, underrated video, underrated channel! Thank you for the work!!
@MarkShead Жыл бұрын
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/
@ralfrolfen5504 Жыл бұрын
@@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 :)
@mauricemakesmovies2 жыл бұрын
I am just starting out in the world of User Stories and your video's help tremendously. Thanks so much!
@RamPMonyPers7 жыл бұрын
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.
@ggkoukla2 жыл бұрын
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.
@raymondmutagahywa99914 жыл бұрын
You hit a lot of points very simply. The 7 minutes literally sped by. Very nice.
@MarkShead4 жыл бұрын
Glad to hear it! Thanks for taking the time to comment.
@degerhandeger78723 жыл бұрын
This clearly and briefly explains what user stories do and why it makes sense to use them!
@Elzelgator2 жыл бұрын
Try it on 1.25 speed. Thank me later.
@neronegronoir79215 жыл бұрын
Mark: Hi I'm Mark! Tommy Wiseau: Oh hi Mark!
@shinygem04114 жыл бұрын
i did nAHT hit her
@jordandesigns57974 жыл бұрын
@@shinygem0411 its bullshit, i dyd nawt!
@sarac.35683 жыл бұрын
This is really great. The best tutorials out there for this particular niche!
@MarkShead3 жыл бұрын
Glad you think so!
@axelvanhooren63255 жыл бұрын
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.
@MarkShead5 жыл бұрын
> 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.
@axelvanhooren63255 жыл бұрын
@@MarkShead Thanks for your response. Best for 2019.
@MrFanaticrat2 жыл бұрын
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.
@jgmarzo34917 жыл бұрын
The animations are GOLD!! Thanks for sharing your knowledge and using your skills to help others.
@SH-xn4rb4 жыл бұрын
pppppooooooooooppppppppppp
@suprabathreddy8874 жыл бұрын
Which software for animation?
@m.vineeth97244 жыл бұрын
Simply excellent. Really appreciate the amount of work put for this. Cheers !!!
@MarkShead4 жыл бұрын
Thank you for taking the time to comment. I appreciate your encouragement.
@MrFanaticrat2 жыл бұрын
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?
@Moccalocca1002 жыл бұрын
shut up you talk too much
@Co0lGwindolyn4 жыл бұрын
Thank you, this video helped me understand user stories. Well explained.
@zeeshankhalid1530 Жыл бұрын
Sir Mark this is truely out of this world, You are amazing
@nayanchoudhary43535 жыл бұрын
Great content, and so is the style of delivery! Awesome stuff! Loving your videos on Agile.
@JulieWork Жыл бұрын
Excellent! Not many people bother to go back to basics to really understand it.
@MarkShead Жыл бұрын
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.
@nkosanam15835 жыл бұрын
Awesome story about user stories. Thanks Mark.
@sandeepkasireddy6 жыл бұрын
Classic examples and good animation! Cheers Mark :)
@selftaughtaigeek98115 жыл бұрын
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. 😊
@alwinmark31754 жыл бұрын
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).
@kindlegatefoundation14607 ай бұрын
Love your work and will love to collaborate. Its been very useful for onboarding newbies and reiterating standards for the old blocks.
@karinasevillano98205 жыл бұрын
Great video. It explained clearly the concept of user stories in Agile projects. Thank you
@keneisele10603 жыл бұрын
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.
@grossteilfahrer3 жыл бұрын
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.
@Paunited113 жыл бұрын
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.
@MrFanaticrat2 жыл бұрын
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.
@sannyboi72982 жыл бұрын
Brilliant and simple explanation.
@MissLOHMORE2 жыл бұрын
this was beautifully explained, thank you!
@christopherhurney59072 жыл бұрын
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.
@MarkShead2 жыл бұрын
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.
@shankarraj34332 жыл бұрын
Thanks for this video tutorial.
@GameoverUK-YouTube6 жыл бұрын
Amazing video, explained so much in a small video. Thank you and I have subscribed.
@MarkShead6 жыл бұрын
Thanks! I really appreciate your comment.
@piotrjugielewicz66346 жыл бұрын
Jepsen yeah homes
@09addzy3 жыл бұрын
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.
@frutiferasornamentais81236 жыл бұрын
It's very good animation whit great knowledge. Thanks for your job. .
@MarkShead6 жыл бұрын
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.
@gillianmbanwi25423 жыл бұрын
This is everything I needed thanks a lot
@paulrajjoseph20164 жыл бұрын
Great Job! easy to understand.
@GeorgeVasiliou-p5t Жыл бұрын
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.
@JabmarMusic3 жыл бұрын
It is a perfect lesson. Thank you for information. I really appreciate what you have done.
@loudufresne61297 жыл бұрын
Very good presentation. Explanations are planned well and accurately presented.
@gopinathanandan13184 жыл бұрын
Good explanation with animations 👌👌👌👌👌... If possible could you please share .. who will write a user stories and use case and with whom?????
@MarkShead4 жыл бұрын
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.
@gbryan9726 жыл бұрын
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!
@MarkShead6 жыл бұрын
Thank you for taking the time to comment. We used a tool called Go Animate. It handles the syncing automatically.
@supershazwi5 жыл бұрын
This is amazing. Thank you for the explanation!
@MsBluSpot6 жыл бұрын
The animations are great is this powtoon u used to make this video ? thx for sharing
@rakeshmandhan68473 жыл бұрын
Thank you, Perfectly explained!!
@ianpatrick233 жыл бұрын
Super helpful, thanks!
@sourcecell78777 жыл бұрын
Nice summary. Thank you for posting it.
@Andrew747X6 жыл бұрын
very good demo thanks
@DJVARAO5 жыл бұрын
Sweet! Thanks Mark
5 жыл бұрын
What a great explanation, thanks!!
@jaimyvangyseghem53282 жыл бұрын
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
@MarkShead2 жыл бұрын
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.
@sumaiyasumi26106 жыл бұрын
this is very help full and amazing, plz make a test case writing example video
@0xgroot3 жыл бұрын
This is incredible! Thanks
@MarkShead3 жыл бұрын
Glad to hear it. Thanks for taking the time to comment.
@safweneyahyaoui13973 жыл бұрын
very helpful and very informative thank u
@suprabathreddy8874 жыл бұрын
Which animation software man! Awesome work
@MarkShead4 жыл бұрын
The software is Vyond.
@BappuDebNath5 жыл бұрын
Slower speed is better. I checked others, but I prefer this.
@MarkShead4 жыл бұрын
Thanks. Appreciate the feedback.
@backester_singhaman69146 жыл бұрын
love the visuals 👌 any on how to gather requirements?
@MarkShead6 жыл бұрын
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?
@backester_singhaman69146 жыл бұрын
@@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?
@MarkShead6 жыл бұрын
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?
@backester_singhaman69146 жыл бұрын
@@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?
@MarkShead6 жыл бұрын
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.
@danielmauriciocastrocortes49535 жыл бұрын
Gracias por compartir el conocimiento! ganaste un nuevo seguidor!
@1081090934 жыл бұрын
Good point on what to avoid (developer stories instead of user stories) at 4:23
@niksprojects5 жыл бұрын
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
@MarkShead5 жыл бұрын
We use a tool called Vyond for these. Best of luck!
@sabrinabaldo85263 жыл бұрын
Excellent explanation!
@esmailiyou5 жыл бұрын
Thank you for the effort, though it was a lot of theory and very few real examples.
@ilyashmyrin89774 жыл бұрын
no, you're wrong, that's visa verse...
@dharmendrarathod70882 жыл бұрын
@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
@MarkShead2 жыл бұрын
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?
@ssssssss131ful2 жыл бұрын
This is amazing ,
@kavyaak71705 жыл бұрын
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.
@MarkShead5 жыл бұрын
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.
@knockmemithun3 жыл бұрын
GREAT VIDEO!!!!
@tumwineaggrey7363 жыл бұрын
Awesome video
@naomigarusinghe514517 күн бұрын
Revisiting.. thanks
@visualpmpacademy22303 жыл бұрын
Great Job
@moconnormurphy4 жыл бұрын
Superb.
@lanacahe Жыл бұрын
Great. video
@alissajohnson26836 жыл бұрын
Just FYI - I noticed a typo, around minute 2, 'susbscribe' should be 'subscribe'...
@alissajohnson26836 жыл бұрын
Otherwise, very helpful content!
@MarkShead6 жыл бұрын
Unfortunately, I can't change an existing video, but thanks for letting me know.
@labiqahali24635 жыл бұрын
From which software u made animations
@suprabathreddy8874 жыл бұрын
Which animation? did u find it
@siv1873 жыл бұрын
Any one has formats for user stories. I'm new to this
@sammyasher4 жыл бұрын
Good content, audio quality lacking. I can hear your room echo/reverb and background noise in the narrative. Isolate and dampen, somehow
@the7ak33 жыл бұрын
@1:51 "keep my ke-count secure"
@appnotiq7 жыл бұрын
please can you tell me what application did you use to make this cartoon and animation?
@MarkShead7 жыл бұрын
Ash Ganatra GoAnimate
@heidersouza7 жыл бұрын
Hi Mark, do you have some help to work with backend develop?
@MarkShead7 жыл бұрын
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?
@heidersouza7 жыл бұрын
Second option, create stories for backend work that a user can't see. :) Btw that was fast! thanks
@MarkShead7 жыл бұрын
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?
@heidersouza7 жыл бұрын
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?
@MarkShead7 жыл бұрын
Does this video help? kzbin.info/www/bejne/e3W3YXuDqamqj6s
@adrianlopeziglesias13 жыл бұрын
Great!
@kamalarora38777 жыл бұрын
excellent..
@abhinay186 Жыл бұрын
❤❤❤❤❤❤❤❤
@kiwislanguagejourney23543 жыл бұрын
Thanks
@jesch30615 жыл бұрын
MERCI
@jansa9403 жыл бұрын
need to put on 1.25x or 1.50x speed
@butiaklein3 жыл бұрын
he keeps his caccount secure....
@NickLogoAbk29132 жыл бұрын
Where’s grounded
@limenpepper2 жыл бұрын
3:39
@divyanshukushwaha38973 жыл бұрын
1.5x speed
@RyanMartinRAM6 жыл бұрын
swallowing noises are seriously stressing me out, I have to watch another video. Please edit the swallowing sounds out. Not very professional
@MarkShead6 жыл бұрын
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.
@RyanMartinRAM6 жыл бұрын
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.
@RyanMartinRAM6 жыл бұрын
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.
@MarkShead6 жыл бұрын
Thanks. I appreciate your suggestions. I actually tried some other settings on a more recent video. Does this one sound any better? kzbin.info/www/bejne/kIvCp6Gnq7xnerM
@WilliamBarker3 жыл бұрын
The developer's story was "bad", but you didn't show a "good" version of that story. Nice work in general though.