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
Post a Comment