Timeline for Points, Hours, Capacity
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 24, 2020 at 17:27 | history | edited | Sarov | CC BY-SA 4.0 |
added 1 character in body
|
| Feb 20, 2020 at 15:20 | vote | accept | Mark Saluta | ||
| Feb 18, 2020 at 16:19 | comment | added | Sarov | @MarkSaluta updated my Answer. | |
| Feb 18, 2020 at 16:19 | history | edited | Sarov | CC BY-SA 4.0 |
added 1060 characters in body
|
| Feb 18, 2020 at 16:01 | comment | added | Mark Saluta | I agree. We'll be making haste slowly toward that end. Following up, assuming that we have addressed many of the Scrumbuts, if I ask for the team's availability during the sprint, and John indicates that he has PTO Thursday and Friday at the end of the sprint, and I know he is going to be out for a total of 16 hours. How does this information impact the total capacity if not calculating based on hours, and velocity has not been established? Feels like hours are needed until they're not. | |
| Feb 18, 2020 at 14:16 | history | edited | Sarov | CC BY-SA 4.0 |
added 592 characters in body
|
| Feb 18, 2020 at 14:12 | comment | added | Sarov | @MarkSaluta Well there's your higher-priority issue. Before you try to fix why your Scrumbut isn't working, you need to actually try Scrum first. ronjeffries.com/xprog/articles/jatbaseball | |
| Feb 17, 2020 at 20:02 | comment | added | Mark Saluta | @Sarov, The team that I've taken over doesn't currently do retrospectives or sprint reviews sadly. There is a plan to improve the team slowly. I've brought up these concerns to the development manager, and we're going to be incorporating reviews and retrospectives, in order to give the team a voice to talk about the above issue. | |
| Feb 13, 2020 at 17:36 | comment | added | Sarov | @MarkSaluta Have you brought that up in the Retrospective? What did the Team think/suggest? | |
| Feb 13, 2020 at 16:40 | comment | added | Mark Saluta | @BartvanIngenSchenau unfortunately, I feel they've been doing that, without clearly defined goals, and being pushed by the business for "more." We're in a bit of a "well, let's just see" mentality. From what I'm looking at in Jira, there hasn't been a successfully committed to and delivered increment for quite a few sprints now. | |
| Feb 12, 2020 at 16:00 | review | Suggested edits | |||
| Feb 12, 2020 at 16:04 | |||||
| Feb 12, 2020 at 15:50 | comment | added | Bart van Ingen Schenau | @MarkSaluta, if you don't have enough data points of past velocities, you can always plan using "collective gut feeling": Add stories to the sprint until a significant part of the team believes the next story will be too much. | |
| Feb 12, 2020 at 8:56 | comment | added | Manziel | This does not really matter. Most estimates are not very reliable as well. The essence of agile is to accept this unreliability and the possibility that you are wrong. In the beginning you are likely not to make your sprint or finish too early because both estimates and velocity are unreliable. After some time this should converge as everybody has a better grasp of what they are doing. You can sanity-check a single sprint planning by checking the progress mid-sprint. | |
| Feb 11, 2020 at 18:32 | comment | added | Mark Saluta | This is just for planning. Unfortunately, there isn't enough reliable data to track the actual velocity. | |
| Feb 11, 2020 at 17:49 | history | answered | Sarov | CC BY-SA 4.0 |