I am currently working for a company that has adopted scrum and we are trying to figure a rule for how to account for tech support, bug fixing and the unknowns of the Apple appstore within our sprints.
Essentially I'm wondering if we build in time for each sprint - say 20% of our time - goes to the above mentioned points.
Any suggestions would help a great deal as I haven't had much luck finding resources for this online.
With respect to releases, you don't need to release after every Sprint. The output of a Sprint in Scrum is a potentially releasable increment. The keyword there is "potentially". Every completed story should meet the definition of done (which should include all related tasking, such as documentation updates, unit testing, integration testing, acceptance testing, etc.). When you decide to release or deploy your product, this lives outside of your Scrum process and someone just goes through the submission process, probably after the Sprint Review is complete and prior to the Sprint Planning for the next Sprint.
Bugs should be treated as stories. Most bugs can be put onto the Product Backlog and ordered like any other Product Backlog Item. However, you may have a high priority bug. If so, the Product Owner may opt to work with the team to decide how to fit it into the iteration. This may involve removing a User Story from the Sprint Backlog and replacing it with the story for the bug.
Tech support, if it is done by the Developers, can be accounted for in the Sprint Planning session. When you are using your Velocity to determine how many Story Points to bring into the Sprint, adjust based on an allocation of time spent doing support work. If you have a consistent 20% of your team's time is spent on technical support every Sprint, then your Velocity would reflect this and you don't need to do any adjustment at all.
Related questions:
I believe the links in the comment to your questions are valid and can be useful to your concrete situation. Especially when it comes to prioritizing work and making it visible.
However, may be there is one more item you might want to look at, trunk-flow. Its basically the flow that the team uses to version its work with git/svn or other systems. Trunk flow says that all commits go to the trunk and that releases are cherry-picked from the trunk and all fixes happen in the trunk. It relates to AppStores release conditions in a way that you could have a release being prepared every two weeks (thats how often Apps are typically reviewed) and this release has all the stuff that has been done so far.
Interesting question is what is your DoD? When a feature is in the AppStore or just ready for release...
