AGILE QUESTIONS Flashcards
Tell me your experience in Agile development process
Our team had 6-7 members. The development was set on 4 weeks release timeline. The Scrum Master conducted daily scrum meetings where we discussed:
Ø What have we done since the last scrum meeting?
Ø Any roadblocks that impact our work?
Ø Report on “to do” items between now and the next scrum meeting
Each member was working on User Stories and moved them throughout the phases upon the completion: Backlog, In Progress, Roadblocks, Done, Acceptance Testing, and Production.
I worked on facilitating communication between cross-functional teams, gathering and prioritizing user stories, and ensuring the product backlog aligns with business goals. I’ve actively participated in sprint planning, daily stand-up meetings, and sprint reviews, contributing to the continuous improvement of the Agile process and helping teams deliver high-quality, customer-focused software solutions on time.
How do you write user stories in Agile?
In a User Story I describe a desired feature in narrative form, and include the Title, Description, Screenshot (if applicable), and How to test it. In my team, for a feature that takes 4 to 12 hours to complete (develop), we need about 1-2 pages documentation (mostly capture of a screen shot (or screen mockup), a primary and alternate work
flows) to document the above items.
Who participates in Agile meetings?
End Users (main representation 1-2 people)
Scrum Master
Business Analyst
Developers
DBA
Testers
What artifacts do you produce in Agile?
The backlog items (including Features, Bugs, and Technical work) we break into User Stories and Epics
Ø User Stories are items that are understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build several of them in single iteration.
Ø An Epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories
In my team, for a feature that takes 4 to 12 hours to complete (develop), we need about 1-2 pages documentation (mostly capture of a screen shot (or screen mockup), a primary and alternate work flows.) to document the above items.
How do you write requirements in Agile?
In Agile Scrum I only documented features that were programed during the current iteration. I’ve done this in my xxx project. For each feature, I needed to have enough documentation to be able to:
- Explain what problem this feature solves (what value it brings to the customer). This will help programmers understand why they are programming that feature.
- Explain what solution has been selected (how the software will be changed to bring that value to the customer). This tells the programmers what to program.
- Identify the other parts of that application that will have to change because of the new feature (to understand the impact and side-effects of the change). This will tell the programmer all the other things he has to change to make the new feature fully functional and fully integrated with the rest of the app.
How do you give the requirements to your team in Agile? Do you hand them out or do you stick them on board?
Each User Story gets a tasks to get them complete. I assign myself a task called “requirement” on “In Progress” section of the board, and then I create 1-2 pager documentation that includes a screen shot (or screen mockup), a primary and alternate work flows, and description how to test it.
When complete (usually in takes me between 2-6 hours), I upload the document in the common document repository, and move my “requirements” task to Complete section of the board.
How big is your Agile team? Do you have single Agile team or multiple teams throughout your organization?
We had multiple teams throughout the organization. Our team was about 7-8 people.
How do you estimate the level of effort of each user story?
During the Sprint Planning meeting, our team and the end clients used to review the backlog and the end clients would pull the user stories they want to include in upcoming sprint. Each user story was assigned a Story Points that represented the complexity of development of this requirement. We used a Fibonacci Sequence as the basis of Story Point values and limited the Story Points to 1, 2, 3, 5, 8, 13 and 21. In my experience, 34 and above is almost always more than just 1 user story. Our usual sprint velocity was 50 points for a 2 week period.
In an Agile team how do you make sure developers get clear
understanding of the functional requirements?
I develop my user stories to answer three main questions – WHO, WHAT and WHY, thus developers would understand what user roles should have an intended function of the product, what should a user be able to accomplish, and the goal of this requirement, describing why are we creating this feature.
I Also write small user stories, which will help my developers to deliver functionality faster in shorter cycles.
And of course, I also heavily rely on the Acceptance Criteria that provides developers and the testers step by step details of how to test this feature.
What support do you provide to developers throughout the project?
My role as business analyst is not simply about documentation. I facilitate quality and timely decisions, and help my stakeholders and development team to discover solutions that are the best fit for business needs. To be specific, some of my support to development team involves:
* helping to remove any roadblocks and impediments that might slow down their progress, like communication with other teams (SQL Support, or Infrastructure) to get their timely support for code deployments,
* Making sure any of their questions related to User Story functionality is quickly addressed and clarified by the stakeholders.
How long does it take for your development team to complete a
8-point User Story?
Velocity of our 2 week’s sprint is 52 points. Since we have 4 developers, each get about 12 points to complete in 2 weeks. Our user stories are usually about 2,3, and 5 points each. Rarely we have the 8 point story, since we always try to break it down to smallest
possible feature.
What tools have you used to capture user stories?
In our current project we use Microsoft TFS for as a user story board. However, I document each of my User Stories in word document, since I usually include an activity diagram, and if possible, a screen muck up, beside providing the narrative and the Acceptance Criteria. This document then gets uploaded in TFS.
In my prior projects I’ve also used JIRA, and the SharePoint Kanban board to manage sprints
What platform you used to track the product backlog and how do you maintain the entire flow?
As mentioned earlier, I worked on MicroSoft TFS, JIRA, and the SharePoint Kanban boards to manage the Agile Board. Same goes for Product Backlog, it’s being a part of the Agile Board. I constantly revisit my backlog items to ensure that all my User Stories are prioritized, groomed and sized.
* Prioritization is done by the product owner, usually one or two working sessions will suffice to complete it.
* For grooming my user stories, I facilitate 2 hours working session each week and I include the product owner, lead developer and the lead tester in these sessions. I try to clarify as many User Stories as possible within these two hour meeting. Then I go back and finalize all requirements, and mark those User Stories as “groomed”.
* Sizing of the User Stories are done by my developers and testers during the sizing sessions 1 hour each week. Product owners are also attend those meetings, but mainly as observers.
If there is any Gap how do you present it to the customer, do you use any dashboard?
Avoiding the Gap in requirements is the main reason why I rely on UML, specifically activity diagram, for each of my User Stories. So it is quite rare when I end up with the requirements Gap, but when I do, my first action is to verify this with my development team, to make sure I myself am not missing anything obvious. If confirmed that there is a Gap, I’ll communicate this with my Product Owner, and we will discuss possible resolution, usually adding some new feature.
.In your current project after a retrospective meeting what
decision you guys have made or the action you guys take for
improvement?
Our Retrospective meeting run at the completion of each sprint. At that meeting, we discuss what went well during the sprint, and what needs some improvements. Few of the examples of what was improved in my previous projects as a direct result of the retrospective meeting are:
* Pull development team out of many unnecessary meetings to free up their time. As result, we were able to increase sprint velocity.
* Get product owners more involved by inviting them to technical team discussions, and user story sizing meetings. This gave product owners better understanding of development process, dependencies, and constraints.
* One of the project initiated end of sprint get away lunches with product owners and were able to create better bonding and relationship with clients.
