Reddit reviews User Story Mapping: Discover the Whole Story, Build the Right Product
We found 5 Reddit comments about User Story Mapping: Discover the Whole Story, Build the Right Product. Here are the top ones, ranked by their Reddit score.
Jeff Patton's Story Mapping, even though it seems more limited from the title, is probably the best introduction on _how_ to do the job.
Pick up a copy of Mike Cohn's User Stories Applied for a great reference on this topic.
Once you have read that I highly recommend getting a copy of Gojko Adzic's Fifty Quick Ideas to Improve Your Stories (also available on amazon)
You could even roll all of that together and run a story mapping session with your team - this will give them a much broader understanding of what you want the app to do as a whole and you'll get a chance to explain your vision.
EDIT: Hit save early, added story mapping & formatting :)
The role of the product owner is a little tricky because there isn't a lot in the scrum guide that tells you how to do the tasks required. A lot of these tasks happen outside the sprint and touch on Agile Project (or product) Management and lives in the realm of Business Analysis. Of course communication with an emphasis on listening carefully is going to be the key skill.
Requirements analysis or requirements engineering is the process that you seem to be looking to define. Searching on either of those terms may prove better results for templates or techniques. That's the process of determining the user needs / wants / expectations and turning those into features.
The first step that I find important is to ensure that the PO has a clear vision of the product. By this I don't mean the details of how it will function but what is the domain the product lives in and what problems it's trying to solve, basically the why of the product.
There are several techniques that can help to define this. Some people like the Business model canvas or the lean canvas filling those even partially with stakeholders can help to define the vision.
Another technique is a version of the Product Box Game that you can do with your stakeholders to help define the features of the product. Imagine what emotional is portrayed by the box's artwork and what features are prominent on the front, what secondary features are detailed on the back.
Books that may assist are User story mapping and the techniques described in there are basically what SCRUM requires.
In the past I have also used some of the techniques in the Rational Unified Process to get a sense of the types of questions that should be asked. I don't want to put too much emphasis on that because I really don't recommend following RUP because it's way too bloated (way more than SCRUM) however, one could easily skim some of those such as the Elicit Stakeholder Requests or the idea of Capturing a Common Vocabulary can be helpful as some people use terms very differently. I don't really want to link to that because I really don't recommend that process but if someone asks I'll link it.
TL;DR check out this video, Product Owner in a Nutshell
It's never too early to familiarize yourself with best and current practices within the field.
I'm not sure what your financial situation is as a student, but I would start by locating and getting in contact with the IIBA or PMI local chapter closest to your home or university. It is an invaluable way to build your professional network, discuss the field, and listen to lectures and presentations built on real world experience.
There are also a number of websites which have useful information about the field (white papers, articles, etc.):
If you are inclined to purchase books, I've found the following very useful in my career:
I would say start with the free websites, immerse yourself in the culture/field and take in all you can. Participate in the r/BusinessAnalysis forum. Finally, network your butt off get a job and start your career.
If you have any other questions feel free to ask or PM me.
As you're both (you and the team) very new to scrum, you should start with some of the supporting basics that help tie everything together.
You're pretty far from the ideal situation, but there's nothing preventing you from learning and growing together. it's much harder without a careful guiding hand, but not impossible. There's a lot of things you're not going to know/understand simply because you haven't been exposed to it yet.
IE: scrum doesn't have a set way to do these ceremonies (other than loose guidelines. the by-the-book approach) because how they are run is environment specific. Most places are not equipped to do scrum by-the-book exactly. IE: they have QA. and QA is not a role within the scrum framework. The team should clearly define the roles and responsibilities of each team member. These definitions will change over time through the retrospective. every standard, process, etc. should be treated the same way. you should always be verifying that your processes are still valid. As the team matures and grows their needs will change and your processes should reflect that.
However this is a 'crutch' for teams that don't understand the retro yet. this format should eventually change, but you won't have to worry about this for a while.
This is the kind of stuff that really differentiates between a scrum master/agile coach and a project manager.
6 months to a year from now, what you're doing should look different than scrum by-the-book. I highly recommend you start reading books to help cover the gaps in your understanding. I suggest you start with Phoenix Project and a book on writing user stories.
The point of a sprint is to iterate. Yes, we also get shippable increments out of a sprint and that's important, but this pales in comparison to iterating against your product (so you can fail faster and get more value to your customer) and your own development process (this is what will truly enable you to iterate faster and faster as you mature)
This means you will often but heads with leadership, as better development practices often require a shift in culture. Ultimately you want to be able to have autonomous teams that are aligned to the business needs.
-----------------------
Recomended reading:
https://hbr.org/1986/01/the-new-new-product-development-game
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509
https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909/
https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/
https://www.mountaingoatsoftware.com/blog