Reddit reviews User Stories Applied: For Agile Software Development

I liked The Art of Agile Development by James Shore and User Stories Applied by Mike Cohn.

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 :)

Can't express how good this one is. Overall, any of Mike cohn' books are all great

https://www.amazon.com/dp/0131479415/ref=cm_sw_r_cp_awdb_t1_scbOAbVTE20NV

Edit: user stories applied is another one of his greats:

https://www.amazon.com/dp/0321205685/ref=cm_sw_r_cp_awdb_t1_WdbOAbZP5TPTC

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.):

• BA Times
  
  
• Modern Analyst
  
  
• Bridging the Gap
  
  
• Mastering Business Analysis - Dave Saboe also hosts a great podcast of the same name
  
  If you are inclined to purchase books, I've found the following very useful in my career:
  
  
• Software Requirements 3rd edition
  
  
• User Stories Applied: For Agile Software Development
  
  
• User Story Mapping
  
  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.
  

Meetings. Lots of meetings. My main responsibility is to analyze the business process for a particular aspect of a company's operations and see how IT systems can improve it. So I'll first interview a number of employees, from worker bees to executives. Then create diagrams and data models to document the abstract and functional business process. Finally I work with the development teams to design the IT system supporting that process. You have to enjoy figuring out how things work, getting into the details of what data gets passed around. Also meeting facilitation, a lot of group discussions on how to improve things. I started as a developer, moved to architect, then requirements gathering, and combined all that into becoming a Business architect. The most valuable skill I bring is an ability to gather and understand how both IT systems work and how business processes work. I mostly specialize in commerce, order management, and payment systems.

A lot of my job is relationships. Meeting people on the business and asking what they hate about how something works. Being interested in a developer's baby they created and how it works. Always asking questions and documenting. A lot of 30 minute conversations at happy hour result in a user story that saves a person hours of time at their job.

One tip I give all my BA's is don't just know what your system is supposed to do. Also learn how the other systems work too. When you know how all the other systems work, you can better understand how to fit your software into the overall ecosystem. You also are building those relationships to other development teams that come in very handy later.

Here's my favorite book on writing user stories to get you started. User Stories Applied: For Agile Software Development

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.

1. Always begin with why. Why do we have planning. Why do we have BL grooming. etc. by understanding the purpose of each ceremony you will be able to better understand how to execute these ceremonies against the context of your organization.
   
   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.
   
   
2. The loose guidelines are a starting point. these are not an end-goal. IE: in the retrospective we typically ask three questions: What should we start doing, what should we keep doing, what should we stop doing. you answer these questions in the context of product (what you're working on), process, and people.
   
   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.
   
   
3. do everything you can to understand the basics of software development. (IE: things that should be done independently of Scrum) These are things like understanding the 5 levels of estimation, the difference between relative and absolute estimations, why the team needs to establish standards for processes and definitions (IE: definition of done, when should something be a task vs a story), the difference between data and information, roles and responsibilities, etc.
   
   This is the kind of stuff that really differentiates between a scrum master/agile coach and a project manager.
   
   
4. Also understand that Scrum is an agile framework. Just like the 3 question approach to the retrospective, scrum is a stepping stone to becoming agile. If you haven't, you should read the original HBR article about scrum to get a better understanding of the strengths and weaknesses of the framework. this should help you understand the 'why' behind each ceremony and allow you to better make adjustments based on your environment.
   
   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.
   
   
5. Think of scrum as a problem finding mechanism and not a problem solving mechanism. This is why the retrospective is the most critical ceremony of scrum. DO NOT WORK AROUND PAIN POINTS. If the team says they feel like they have too many meetings, figure out why. If something took longer than expected, dig into what dependencies were missed in planning and take steps to make sure those aren't forgotten again.
   
   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
   

I reccomend that you read this and follow his blog too, he's written extensively for this subject amongst others

User Stories Applied: For Agile Software Development (Addison-Wesley Signature) https://www.amazon.co.uk/dp/0321205685/ref=cm_sw_r_cp_apa_i_09mQCb22J357P