Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Sprint Planning #221
Based on our discussion at standup this week, I relayed our discussion to Robert and he felt that being a week off sync (based on my 4 week sprint proposal) from the user team may be a nuisance. After speaking more with Orta I think we could try 3 weeks, see how it goes and add more time if we feel it is necessary. As I outlined above, this suggests that we should base the scope of each sprint off a 2 week development period (writing new code) instead of a full 3 weeks. We leave the last week then for QA and bug fixing with a goal of deploying a new build at the end of the 3rd week.
This is not by any means final I am looking for your feedback!!!
I think this looks great
Possibly the only thing we might want to plan in is to force doing another short round (e.g. 1 day) of stress testing after fixing bugs and before submitting. Regressions are more easily made in the heat of the moment.
2, 2½, or 3 weeks is just arbitrary at this point anyways, so see if it works and adjusting based on experience sounds like the way to go
One of the aspects that I found interesting is that it gives a nice cadence to features vs bug fixing. It's hard to get a sense that we'd be doing "too much cleanup / bug fixing" when 1/3rd of the time is spent on it. But always better to start with something and evolve then to try mastermind something perfect IMO.
I will be sending a larger email update soon but wanted to let you all know that after speaking with @alloy Robert and @orta we'll be splitting off from the User Experience Team and holding our own prioritization meetings as the Consumer Mobile Apps team (Eigen and Eidolon). This will include a new sprint schedule that runs six weeks instead of the previous three.
We'll start the sprint with a prioritization meeting where we discuss what we want to include in our next release. We will have support from product ops to looking into KPIs to identify how the app is preforming. There will be four weeks of "build time" after which we will get together to discuss what got done in the build phase, what didn't and why, and determine what will make it into the release candidate. The following two weeks will be spent perfecting the release candidate (bug fixes etc.) and we will release at the end of the six weeks.
Even though the sprint is 6 weeks long, our prioritization and planning should be based on what we think we can feasibly build in 4 weeks. We will use that hard stop to evaluate how good we were at estimating and what adjustments we can make for the future.
To help facilitate, @alloy will be Eigen's lead engineer, practically meaning that he will be responsible for assigning issues. Issues will by default be assigned to him and other team members and he will offload to the rest of the team, seeing as he has a better understanding of everyone's strengths and weaknesses (more than I do!)
I think operating as a separate team will be great for us and will allow us to focus more on how we're impacting Artsy.
Let me know your thoughts or if you have any questions!