Splitting User Stories - Agile Practices
HTML-код
- Опубликовано: 4 авг 2024
- Creating Agile software means you need to be able to prioritize different pieces of functionality based on how valuable they are to the customer. To do this you must be able to break large stories down into smaller ones. This cartoon shows you how to do that. 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 RUclips. You can signup for a copy at this link:
www.xeric.net/#starting-agile 
Наука
![NoCap - Maliboo [Official Music Video]](http://i.ytimg.com/vi/FUV7E0QyniU/mqdefault.jpg)
That's BY FAR the best explanation for this topic I've found on the Internet. Simple, easy to understand and straight to the point.
I showed this in a workshop to my team and they enjoyed the video!
Great! I'm glad to hear they enjoyed it!
wow, what an explanation. As a team lead developer who wants to transition into agile its a really a breeze to find such easy to understand tutorials on the net for FREE!! Thank you for the good work
Love this illustration, this is how agile development should be..Thanks Mark
Really impressive tutorial... everything made so easy to understand... yes, many of us know this but to explain it in such a way is an art... Thank you for this.
Omg! This is by far the best explainers I have seen on not just Agile but any project principles for that matter, this is gold.
"Small enough to be completed in a reasonable amount of time while still being valuable enough that they represent progress to the user.".. Golden advice
Thanks. It is surprising how difficult it can be for a team to find that balance.
This statement looks agile in itself as the sum of everything he pointed out in one video. This single statement is already a great value to the audience.
What a comprehensive, yet extremely easy to digest overview. I'm subscribed and hooked. Thank you very much
The best I have seen. Your animations make it very engaging. I watched the entire video twice
I have been searching for something that would explain to a person coming from a conventional background like me on how we can split user stories. Finally found a video which explains it in such a simple and intuitive way. Thank You.
I'm glad you found it useful. Please pass it on if you have any coworkers who might benefit from it as well. Thank you for taking the time to comment!
One of the best explanations I've seen. Kudos team!
Thanks for the videos Mark, you have very good content and i would say point on to clarity. Really helpful!
Man, I'm SO glad I stumbled upon this channel! Excellent explanation of topics that I didn't quite understand. Thank you Mark!
That is an excellent question. We have to be careful about making analogies to buildings because concrete is very different than Code. If you approach creating software with the idea that you will need to change it in the future, you will invest in very different types of things. For example if I recognize that there are many unknowns, and I recognize that even the stuff I know today may change in the future, then I will be much more willing to invest in comprehensive testing that will allow me to make flexible changes when they are needed.
Sometimes it is better to embrace the fact that we will need to rework and build it into our processes instead of running way ahead of ourselves to fix a bunch of hypothetical problems before they actually occur.
In your database example. If we embrace the idea that it may need to change in the future, we will probably be more willing to invest in some type of comprehensive database schema management. It doesn't have to be necessarily heavy weight, but it does need a way to be able to get the database into a new state whenever it has change from version to version. Flyway is a good example of that, but there are others as well. I've been on projects that have used tools like this, and it's amazing how often the database changes during the development process. If we didn't have a good tool to make the changes developers would continue building on things they knew were sub optimal until it became a problem. Since they have the flexibility to make changes whenever they see they need to be made and it is not expensive in terms of time, the database continues to evolve as the developers understanding of the problem space becomes more clear.
Very well explained with right examples. I had same questions coming from a waterfall model background.
Thanks for this Mr Mark Shead, I have learned a lot this Tutorials.
Really EXCELLENT video to explain the concept! I'll be using this in a training tomorrow. Thanks for this.
That's great to hear! What did people in the training think of the video?
Your tutorials are very easy to understand and nicely animated :) Thank you!
I really enjoyed your videos...great job!!!
BACH needed the paper to write down his bars, same as you do not need every table created in a Database, but you still require a DB instance to support the developer when translating a user story to code. I understand the principles of splitting to smaller stories, especially when time is required to set up the DB & Web Tiers for example - great tutorial
Excellent video very helpful and very well explained. thank you
Very well explained using user and manufacturer perceptions of a cake as an analogy
The comparison with the cake (Layers vs slices) is fantastic as metaphors!
Glad you found it useful!
"The layers vs slices" and "the composer writing music" analogies are awesome - thank you, Mark!
Really great tutorial! Thank you for waking up lot go good thoughts in my mind!
i do this at work and it enables me to supply something usable as quick as possible and i could get feedback, then i enhance it as time goes by. this way, a system can already be used and start bringing value quick then the conveniences come in later. this is also a very safe way to work since you will learn what the user actually wants along the way instead of building a big thing only to realize that he doesn't want it.
Your Videos are so educational and entertaining. Which is a killer combination to achieve. Thanks for uploading videos.
So glad you are finding them useful!
Amazing video and analogies with the cake slices and music sheets
What a great video ! Thank you
Like your videos Mark & their emphasis on the Agile Principles. FYI These "User stories" seem similar/analogous to "use cases" in UML and "work products" in PERT/Gantt project planning terminology.
They do fill a similar role, but are typically much lighter weight since the details can be worked out in a discussion right before or s the code is being written.
Love your analogy of creating music vs house
Great job man👏👏
At last I understand the 'cake / slices' scenario. Thank you
So glad it was useful!
Thank you so much for such a good quality video!
Thank you for taking the time to comment!
Thank you so much Mark, also for your great book!
I'm glad the book and videos are useful. Thanks for taking the time to comment.
great explanation - resonated well!
Thank you so much for taking the time to comment! It means a lot. I'd love to get your opinion and feedback on my other videos too.
Nice explanation, thanks
Impressive Video!!
Simply brilliant...thx
Thank you for your kind words!
The illustration at 2:29 on how a developer sees an application as a collection of layers of cake on top of each other, but the user sees the application as a collection of slices of cake that represent the different things they need to do.
Takeaway:
- In agile practice (agile board) focus on user stories, not developer stories.
- Tasks/Tickets should look like "Build invoicing feature", and not like "Complete the CRUD of service X".
I'm thinking the layers could be thought of as concentric circles on the slice view.
Our PO has allowed our devs to basically set the standard for writing stories in a task method (layers). I'm trying to push for this but so far, no luck as keeping devs happy is more important than doing things the right way.
@Mark - You have cleared my years of doubt.
excellent perspective
nice vid thanks mate
Very helpful! Thank you! My next learning is how to breakdown stories even further into tasks.
I saw this and chuckled. as it's always made a mess of. I'm a Program Director but came through the technical/functional consulting route. Project Management creating build tasks is a dangerous approach. It's much better handled by a solution architect or some other design authority so they can influence the task creation to match their envisaged design.
@@tommorgan6665 why wouldn't the person who actually performs the work breakdown the work? that's too far reaching in my view to have someone else authoring the tasks.
@@ProjectMgmtMadeSimple so hypothetically a user story has elements that effect 6 systems in a technology stack. So 6 developers will have tasks associated to the story. Let's also say the story is linked to another story and needs some element of design. You'd have to hope that all 6 Devs can agree on a single pattern and have foresight on their side. Seems like your approach would work in a very simple project...but not in something trickier
@@tommorgan6665 not necessarily, if a team is cross-functional, one resource in this case should ideally be able to handle all of this. Otherwise we have a bottleneck issue. Either way, yes the team has to agree on an approach.
@@ProjectMgmtMadeSimple feels unlikely to me that one person whos job it is to provide overarching direction and steer(a solution architect in software projects) is going to take longer splitting out a user story into tasks than it takes the devs to develop the last one.
Hi Mark very helpfull and Thank you so much . Please take a lesson on BRD ,FRD and RTM.
Rachel Dorthy Thanks for your comment. I'm glad it was helpful. I'm working on a video covering Behavior Driven Development as a way to gather and create executable requirements for software projects. Hopefully I'll get it out in the next few months. Thanks again and don't forget to checkout my other videos and let me know what you think.
Thanks for these Agile videos. They are fantastic and very helpful. We are trying to use more Agile principles in our team. Question: when using an agile approach, where we can't be completely sure of the user's detailed requirements at the start, how can we give estimates of timescales and plan the overall project and know we will hit the target end date?
Thanks for your comment! It sounds like you are assuming that you by producing detailed requirements you have complete certainty that you will meet the target end dates. Is it possible that you are overestimating your accuracy? Most teams estimates are pretty bad even if they have put a lot of time into requirements. Agile basically says, don't waste time on detailed estimates that aren't valuable and instead spend that time writing useful software. Use your track record from the last few months to estimate how long future work is going to take. If you are delivering usable software and completing the features with the best return on investment first, your organization can focus more on just having the team produce software until the expected return on investment of the next most important piece of work is lower than the expected cost--based on how long it is typically taking to finish features.
Does that make sense? It is a different approach, but driven by producing business value rather than guessing at dates.
Thanks for taking the time to reply. Yes it makes sense, although it will be harder to explain this to users who often want to know 'when can I have it by?' Also I'm in a team which is required to build an application, then move on to the next application (whilst supporting all the previous apps) This is a challenge because we need to give users a sense of when the next project can be started. I still think it's worth taking the agile approach though, if only it gives 'some' useful software.
Nice tutorial
how you make animation brother.
Great
What would you suggest for a multi platform app? For e.g If the application is working on 3 different platforms (Android, iOS and Web) then should we create 3 separate stories with same title for each platform? Or one Story and 3 sub tasks for each platform?
I'd recommend looking at something like flutter.dev/. If your app is something that fits well with it's model, it could be a way to create a lot of value very quickly across multiple platforms.
How is this free? This is so well made!!!
Nice one
Thanks! I glad you enjoyed it.
What if your slice of software is built of many other slices that only have value when they're all together?
For example with a house, its only valuable when it's built since you can't use it otherwise.
Very good question. In my experience using building a house as a metaphor for building software leads us to assume that if something isn't possible with bricks and boards, then it isn't possible with bits and bytes. In almost every software project there are pieces that can provide business value without completing the entire project. The exception would be software where the entire thing must be certified before it can be used like an airplane control system. In those situations, you will have to settle for creating a slice that can be *demonstrated* even if you can't actually take it through to production.
But with the vast majority of software projects there *is* a way to build slices through the system that can be used as you build it. Slicing things in this way requires really understanding what is valuable to the person who is going to be using the software and takes a lot of back and forth between the developer and the user to find the overlap between the things that can be built independently by the developer and the things the user could actually use right away.
Itamar, keep in mind that the idea of the slice doesn't always have to have every layer fully created to support it. Let's say you have to build a system that 1. receives an incoming API message, 2. extracts data and 3. applies one of numerous workflow steps that depended on message/scenario type, 4. transforms it into a second outgoing API to 5. deliver to a customer server.Our developers first tried to build step 1, then 2, then 3, then 4, then finally 5 they hit the destination server. This whole thing took 10 weeks. When they finally hit the destination server, SURPRISE! they found out it used a different security protocol and they had a lot of rework.Instead, the next time, they mocked up a received message, skipped the workflow and logic and triggered a mocked up "transformed" API message to hit the destination server. In one week they simulated a received message and hit the server, and got an expected error message. But this tested the design and validated that communication with the server was open.Then they began building the internal steps one at a time. They handled 1 scenario at a time, rather than code for all. They picked a thin slice of the workflow logic, and designed the outgoing API based on that one scenario. At first this was "hard" but soon they got very good at it.
I'm afraid you may have missed the point.
Working with stories means that you may NOT build slices. You may, but usually you don't.
In the current example, you could replace the database by a static file with some functions that get the list of items/description/price/link to image, and that's all for now.
Another story will be "instantiate a real database" (and another one will be "add an item to the database", another one will be "remove an item from the database", and so on.
Yes, so small. And "manage the items in the database" is an epic or a feature, NOT a story.
HTH!
> Another story will be "instantiate a real database"
I know there are people who try to practice creating stories like this, but just to be clear this is exactly what I'm saying you should avoid. I would suggest that you create a real database when you get to the first story that needs a database.
I think there is real risk in this approach. Modern customers are very picky when it comes to user friendly and convenient software. Imagine if we put up a site with very basic information and actual end users can find, what would happen. People use search engines and probably our site is on the hit list, compared to other competitors, customers may never come back.
I would also recommend you to make a tutorial in TDD and Unit Testing using any Java, C# Programming or Android Development.
Thanks. I have a few more planned.
Thanks Mark Shead
Or FullStack. HTML5 and javascript are far from being behind you know.
Poggers, Mr Shead
Nice explanations but there are several forces here. The smaller you make the stories the more interdependence you have between them. Story mapping or starting with usage scenarios can help here. The goal shouldn't be to split the story into something that can be done in 2-3 days. That's wildly arbitrary. The goal should be to break the story down as small as possible while still deliver value. In iterationless methodologies, smaller stories becomes an optimization rather than a requirement to fit in an iteration. I advise teams to start by making the stories small enough to fit in an iteration. Then offer techniques for splitting such as using the Acceptance Criteria as and outcome based value for a story to split off from.
Yes the stories should be something the can demonstrate value. That is what I was trying to say when I said that the stories have to be something that represents progress to the user. When my company is developing software for clients, we aim for stories that we can complete in a single day. My experience has been that if a team can't deliver something in at least 2 to 3 days, they are batching things together more than it needs to be or there are other problems with their development process.
How to move stories in jira
If you are talking about a JIRA board, you should just be able to drag the cards to another column.
Hi Mark, I work as QA and since last 1 year using BDD techniques for writing user stories in 3 amigo sessions.
Please share your thoughts on breaking down "Big Story" into small meaning chunks with help of "Example Mapping" techniques in cucumber website.
Example Mapping helps in creating Rules & Concrete Example and prioritize those for each sprint. Thanks in advance.
Example Mapping can be a very powerful tool and is definitely useful in many situations. I think it can be especially useful when you are starting a project and it is hard to see ways to break stories down into smaller units. Once a team is established and you have a deployed application that you are continually making changes to, you are likely to find that people naturally create appropriately sized stories and only fall back to Example Mapping when they get stuck or need to show a new person how they are thinking.
Just make sure that you don't let your team think that Example Mapping is the goal. The goal is to get a stream of valuable functionality flowing into production and you do that by creating small independent stories. To the extent that Example Mapping facilitates this, it is very valuable, but you have to keep the mindset that it is just one of the tools at your disposal. Make sure you are paying attention to how well your tools are working for you so you can adapt as needed in the future.
Hope that helps!
Please clarify below
1. who are the "people" in your comment ?
2. So per your comment you just rely on someone's experience to break down user stories ?
3. Why can't 3 amigos sit together and do example mapping for each sprint ?
I feel it's riskier if we just ask people to break down stories without any tool / methodologies.
When I said "people" I was referring to the team as a whole, but especially the people asking for new features--which is typically the product owner.
If the team has a lot of experience breaking down stories (using Example Mapping or something else) into small, independent, deployable chunks they will eventually internalize that approach in the way they think about new functionality.
If you are getting good results with Example Mapping, then, by all means, keep doing it. :) I was just saying that if you have product owners who have spent a huge amount of time going through the example mapping exercise, you may find that they start simply creating new functionality requests that are the size that they can be coded independently. So basically they get to the point that the Example Mapping becomes just a natural part of the way they think.
Thanks for clarification.
What is this tool that u created this unique videos? Plz
We use Vyond.
@tavga...thanks for the question...i was looking for this :))
oh yes me like GOOEY layer!
Can you make one tutorial for how to make BRS document....
Thanks for the suggestion. I don't use BRS documents with any of my teams so I'm probably not a good person to talk about it. The teams I work with are typically using Behavior Driven Development so teams collaboratively develop executable examples of the functionality. If you are interested, here is a video that gives you an overview of what that process looks like: ruclips.net/video/ydddSkVz_a8/видео.html
Had I seen these vidios of yours in 2016-2017, I would be a completely different, more susccesful BA.
Thanks for your kind words. I hope they're still helpful to you today.
Yes it did. Still .... not easy with only backend team
Heider Souza so are you working on thing the users are asking for as valuable?
Yes we are :) It's just struggling with new team with old mindset in a old/new industry as mainframe. It's a good challenge for me, discovering new ways of communicating... Everyday one more step in the head of the developers..
First explains the programmer thinks of things as layers and you need one layer to build the other but later on, in the final story, assumes database is already done so bottom layer is already there.
Thanks for the feedback, maybe I need to make that point more clear. Later on assumes that you have built the bare minimum necessary to finish the previous story. So there is a minimal database layer and you have to build out whatever else you need to support the current story. For example, you don't have to fully model your domain in the database first--just the part you are building enough to deliver working software.
Does that make sense?
Mark Shead... his profile picture is Mark's Head.
Very true!
@@MarkShead is your last name actually Shead? Because that is pretty funny to me if so. Love word play in names.
@@AbraxxasJW Yes my last name is indeed Shead. :)
Mark your still walking at 6:58
This is a great video..Can I translate into Japanese?
The problem with the principle is that you don't think much about scalability and security, all this are of less value over ensuring that the customer sees progress, ofcourse it is important the customer sees progress but what happens in future when we realise that the software has a serious business impacting bug or security issue because all of our focus was on realise not quality.
The successful Agile teams I"ve been part of focus on working software, but don't forget that the definition of "working" is that it can do actual work. So any required security and scalability gets baked into the process. If a batch process needs to be able to handle 1 million records in 15 minutes, one of the first things they do is setup a CI process to run a million records through it so it will fail if they stop meeting their required target. If there are specific security requirements that have to be met before they can say that software is done, then they are built into the process and applied to each bit of code that they say is finished and ready to demo.
Agile works very well when it is done well. It works poorly when teams do crazy things and just call it Agile as an excuse to continue doing crazy things. :)
If you are customer focused it is inevitable that you will want to get the User Interface done first. It is 99% sure that the customers will want significant changes. You do NOT want to spend two years perfectly writing the wrong code to the wrong specification. It is incredible hard to start out with a blank piece of paper and describe the perfect finished system. If you have the technical knowledge to write a software specification it is unlikely you have the domain knowledge to know what needs to be done., Users are non-software people and may have in depth domain knowledge (correcting an error in the general ledger after the monthly statement has been closed out) but look at the world very differently than software developers who have to worry about "how do I do that?" If you start out with "how do I do that?" you will end up with an ugly "what do I allow people to do and how do they do it". Amazon and Google have nearly invisible interfaces because they have really looked at how users want to use something. Not how the software is structured to accomplish the objective.
Well, this is a very good presentation, but the title should be "WHY splitting user stories".
The hardest part is, in fact, HOW to do this. And that's another …story.
Excellent Tutorial but the animated cartoon character... really differ from your actual face.. haha
The only thing I don't understand is: How can you keep talking as if nothing when you are being electrocuted?
Like Westley and Iocaine powder, my cartoon avatar has spent the last few years building up an immunity to electric shocks. :)
You think its a good idea to throw products online and have customer call a number to order? You understand that requires having a call center set up and may result in much bigger cost compared you if you accepted online orders.
You might be surprised at how many small businesses operate without a call center. They have no problem taking and shipping orders over the phone from their small group of loyal customers. But please don't forget this is an example of how to split up and deliver value incrementally. If you have 10 million customers, maybe your approach would be different, but the point of the approach remains the same.
G U I. Not gooey
Did you see the word "gooey" in the captions or somewhere else?
Why can't you explain in terms of how things are actually done at work using the appropriate technical lingo? Your audience is NOT a 5th grader. Your audience is a technical person who has the know how about how agile works but may not know the details.
Thanks for your feedback. What did I say that you felt would be better expressed in technical terms?
@@MarkShead you are using very simple examples which is appropriate for a non technical person but as an IT business analyst who has only done waterfall project but who wants to get speed up in agile, you need to give more real life examples. Show, using your cart example, what could be an epic and how would you splinter it into user stories which deliver value. Explain how coding a cart delivers value and in what way? Cash? Time? Or what? Can you actually put a dollar value to a story? Such as this story will earn you $1000 or so
this is complete bullshit
How so?