from reports

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

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?

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.

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

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

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.

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
3. Put Story Points to it, keeping in mind days required for the story
4. Give an arbitrary point to the story. This becomes our baseline for story point
5. Using baseline story point we can either go up/down on story points for all subsequent stories