Agile

Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams

9
Posts

50
Members

23
Followers

Topic menu

Stream CLIPP Knowledge

what is this You must accept embedded acknowledgement.
john Arias

Oct 12, 2020

from reports

what is this
You must accept embedded acknowledgement.

How is sprint capacity determined in JIRA Agile?
Reena Garcia

Oct 28, 2019

how is the sprint capacity for planning and burn-down estimation determined?

How is sprint capacity determined in JIRA Agile?

I am new to Agile methodology.
Nicholas Marshall

Oct 21, 2019

We have planned a 6 sprint project. Right now we are on the 4th sprint. The customer wants a small sprint of 14 days at the end of the 6th to solve the bugs that are from the previous sprint. Please confirm if this is the right approach?

Faisal Khwaja

Jan 29, 2018

How much to provide in a story? What is the correct amount of information that a PO should provide for Agile Team? I have written User Stories with varying length and have received different opinions on them. However, the best received User Stories from my team has been the one that are shorter that can be easily comprehended by entire Agile Team. Testing is made easy as well for these stories. Additionally, I usually attach screenshot of specific UX area and not the entire page. This helps the team to focus on just that area and not get side tracked by other details on the page.

Faisal Khwaja

Dec 8, 2017

Following are few things we should follow religiously while doing development in an Agile Methodology: 1. Prioritization MUST be done thru proper channel. No new work should be taken without following the process i.e., Stories should be prioritized by PO and not be coming from the sides. 2. Proper Story Grooming should be performed on a regular basis. In helping development team to deliver what is asked 3. Retro should happen on a regular basis, every week (if it's a weekly sprint like ours) to learn from your past mistake. Also, make sure to track what was suggested in previous retro and define KPI on the trend of past mistakes. This will help you determine if you are doing better, worst or no change. 4. Stories should be properly written and documented. No work should commence without having properly written Stories 5. UX deliverable dates should be factored in when estimating sprints. Delays in approved UX will impact your overall delivery of sprint. If possible add a new column to the story to dictate when UX will be ready/delivered

Fayyaz Shah

Dec 7, 2017

this is a good article, but my question is that do you use same baseline from sprint to sprint, for example, if in sprint one i said a story is one story point and then in sprint three, will I use sprint 1 story as a baseline to determine the complexity of the stories in sprint 3 https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours

Faisal Khwaja

Dec 7, 2017

How to decide what to deliver? We can use our average velocity from last 5-6 sprints to predict our next sprint(s) deliverables. However, keep in mind holidays, time-off and un-seen circumstances that will prevent work from being done from development perspective. We have decided to include "Available Days for Sprint" factor when determining what can be delivered in the sprint. This factors in TRUE AVAILABILITY of our resources in a given sprint and helps dictates what can be taken in the sprint.

Faisal Khwaja

Dec 7, 2017

For our development projects we follow this process: 1. Review User Story with the SCRUM team. This includes SCRUM Master, PO, Dev/QA/DBA members 2. Identify the tasks required for user story and how long it will take 4. Put Story Points to it, keeping in mind days required for the story 5. Give an arbitrary point to the story. This becomes our baseline for story point 6. Using baseline story point we can either go up/down on story points for all subsequent stories

Faisal Khwaja

Dec 7, 2017

In agile development there is always a confusion around Theme, Epic and User Story. Based on my analysis and reading here is what constitutes each: 1. Theme - If you have related user stories but can be delivered in different sprints then it becomes a Theme 2. Epic - Epic is nothing but a large story. This warrants to be broken into smaller User Stories. Think of this as an abstract level container for many other stories. Epic is not complete if all related stories are not done 3. User Story - This is the granular level of requirement. This is where the SCRUM team start estimation