Skip to main content

Best Agile Practices to Follow

Like I mentioned in my previous blog post I will be elaborating more on what are the best practices we can use when we're working in an Agile environment.


I hope you all are familiar with the term Agile and we can easily put it as building a software incrementally from the start of the project, instead of trying to deliver it all at once near the end.That's simply what Agile means. 
Scrum is one of the subsets of the agile methodology and the most widely used framework process in agile development. (A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints) 

I am purely writing this blog post based on my professional experience which I gathered when working with an agile environment. 
  • Plan your Sprint at least a week prior 
As business analyst you have to work closely with the scrum master (Scrum master is the facilitator in the scrum or the agile development) to plan the sprint ahead. Don't wait till the last moment to plan the sprint. Make sure you have enough user stories prepared to the sprint so that you can get the full Velocity out of the development team. It's not a good practice to take user stories in the middle of the sprint.
  • Have a requirement walk-through session (User Story Review Session) with the development and QA teams prior to the backlog grooming session. (Backlog grooming session is the place where we can get estimates to the user stories)
This is also a very important practice to follow and I personally do this with my teams all the time. Understanding is to walk-through the team with requirements/user stories and get their inputs. In this way we can reduce the ambiguity and lots of questions when it comes to the backlog grooming sessions.
  • Plan the backlog grooming session very well 
Now for this you have to be prepared! 😎
This is the place typically where the BAs get so many questions. That's why I told you all to have a requirement walk-through session before so that we can get less questions from the technical teams. 
Before the session make sure you send the user stories to the teams so that they can also read from their end.
  • Have small scrum teams 
It's part of the agile scrum process that we do have a daily update as in daily stand-ups with the team. Don't have larger teams as your scrum teams. Have a small team (maximum 6 members). Daily stand up meetings are supposed to me maximum of 7-8 min of your time. But what happens if you have a larger group like 15- 20. Then it will take more than 15 minutes to have the meeting and trust me you don't want that. So make it simple. Have a small team and just give the update as "What I did yesterday and What I'm planning for today and any blockers for my work. That's it Easy peasy lemon squeezy 😁
  • Don't forget about "Sprint Review" session 
After every sprint there has to be a sprint review session where the team members are demonstrating what they did during the last sprint. Trust me this is very important as BAs because this is the place where developers showcase the user story and if you have any concerns of if that's not how you convey the requirement raise your hand and point it out.
  • Finally the Retrospective 
This is the place where the team members can voice their concerns or suggestion to be heard. Once in every 3 sprint (there is no hard and fast rule for that) you can have a session and discuss What went right, What went wrong and What are the improvements to be made for the scrum. 

Basically these are the best practices which I can point out when it comes to the practical world.

Comments

Popular posts from this blog

Brainstorming Techniques for a Business Analyst

Brainstorming is my favorite and in my opinion the most productive method or the technique one can try out when it comes to analysis or trying to solution a problem. It’s a very simple method and I will point out some techniques which you can use during your session. 1. Be very thoughtful when you are selecting people 💡 You have to get the most productive, solution oriented and technical people into this. In my work I usually invite, The product owner or BA - Who knows in and out of the product from customer point of view The architect or the tech lead - They know the functionality of the system and the technical aspect of it  Solution architect or engineers – So we can have many solutions on the table  QA – Because they think in different angles  2. Do your homework and be pro-active Since you are going to be the organizer of the session you have to know what the problem you are going to discuss, give them a background as to why we need to hav...

What is a User Story and Tips of Writing an Effective User Story

What is a User Story ? We can define a user story as the short and simple description of a functionality used in Agile practice. Basically they are written to capture the requirement from the customer or the end user perspective. It will simply say What type of users, What they want and Why they want it. The user stories should be written in a language where it is clear to both the customer and the development/QA teams as to what the customer wants and why he wants it and what kind of customer wants it.  Development team should understand the customers need and they should take care of how to cater the requirement from technical perspective. There is a simple structure to a user story. As a <<CUSTOMER TYPE>> I want <<WHAT CUSTOMER WANTS>> So that <<WHY CUSTOMER WANTS IT>>  Let me elaborate more on this taking an example.  Assume a tutor wants to publish his/her tutor services for students online for...