You actually have two questions. One is about time-boxing, and the other is about estimation.
Time-boxing and estimation are the very essence of Scrum. If you aren't adapting those two practices for your team, whatever you're doing isn't really Scrum.
Tools and Practices Aren't Silver Bullets
[Incremental development] just doesn't seem to bring enough goodness to our team.
Time-boxing is a tool. It is not a goal in itself, it is a means to an end. Objectives for time-boxing include:
- Composing more granular user stories.
- Applying implicit work-in-progress limits.
- Improving the accuracy of estimation.
- Developing a predictable cadence within the project.
Time-Boxes: Essential to Scrum
[H]ow valuable exactly is it to keep a timeboxed iteration?
Time-boxing is essential to the framework. It ensures that work is properly sized, that features are scheduled based on team capacity, and that the project has a tight feedback loop for its deliverables.
The length of the time-boxes can be adjusted, but you can't do without them. In fact, sprint length is one of the most effective control dials for a project.
- accelerate the feedback loop.
- increase process overhead.
- reduce implicit WIP limits.
- reduce maximum work-unit size.
- reduce cycle times for properly-sized work units.
- reduce process overhead.
- increase maximum work-unit size.
- usually increase the effort required for feature integration.
- increase time available for implementing process controls at the cost of higher cycle times.
You have to find the optimal sprint length for your team. It is very likely that one-week sprints are too short for your organizational requirements.
Time-Boxing and Estimation Work Hand-in-Hand
[T]here has never been a sprint where we successfully complete ALL planned tasks. We always complete most of them, but there will always be a few left into the next sprint. Maybe it has something to do with only 2 people are contributing to estimate[s.]
I'm going to make a few assumptions here. First, you don't have sufficient team buy-in or participation to rely on your estimates, and so you discount the value of estimating. Second, because your work is improperly estimated, you are pulling more work into each sprint than your team capacity can support.
All teams occasionally miss commitment targets, but routinely failing to meet them is a sign of a fundamental process problem. In your case, this is likely due to improper iteration length, inaccurate story estimates, or stories being shoveled into each sprint from outside the team without regard for WIP limits or team capacity.
You can improve your team's estimations over time by using some widely-accepted practices. Some of these practices include:
- A formal Sprint Planning session where the whole team participates.
- Planning Poker to encourage unanchored estimates and prompt discussion about variance in estimates.
- Sprint Retrospectives where estimates can be reviewed to identify lessons learned about the team's estimating process.
- Promoting collective ownership or swarming instead of assigning stories to individual team members.
You can improve your team's velocity and story completion rate by following the framework's guidelines. Best practices include:
- Adjusting sprint length to the optimal size for your typical user story.
- Revising your velocity expectations downwards when commitment targets are not met.
- Limiting stories accepted into each sprint the lower end of your predicted velocity range.
- Working with the Product Owner to decompose user stories that don't fit within a single sprint.