New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sprint Planning #221

Closed
katarinabatina opened this Issue Feb 26, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@katarinabatina

image

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!!!

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Feb 26, 2015

Member

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 👍

Member

alloy commented Feb 26, 2015

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 👍

@ashfurrow

This comment has been minimized.

Show comment
Hide comment
@ashfurrow

ashfurrow Feb 27, 2015

Member

Looks good to me!

Member

ashfurrow commented Feb 27, 2015

Looks good to me!

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Feb 27, 2015

Member

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.

Member

orta commented Feb 27, 2015

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.

@alloy alloy modified the milestone: Sprint Feb. 18–Mar. 11 Mar 2, 2015

@katarinabatina

This comment has been minimized.

Show comment
Hide comment
@katarinabatina

katarinabatina Apr 20, 2015

Hey team @ashfurrow @1aurabrown @orta @alloy

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.

image

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!

Hey team @ashfurrow @1aurabrown @orta @alloy

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.

image

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!

@ashfurrow

This comment has been minimized.

Show comment
Hide comment
@ashfurrow

ashfurrow Apr 20, 2015

Member

Sounds really awesome!

Member

ashfurrow commented Apr 20, 2015

Sounds really awesome!

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Jun 29, 2015

Member

This is what we’re doing now 👍 Closing for now.

Member

alloy commented Jun 29, 2015

This is what we’re doing now 👍 Closing for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment