The average Scrum team delivered a 35% improvement in velocity at Yahoo where teams properly coached delivered 300-400% improvements. The best Scrum Master at MySpace peaked at 267% of initial velocity after 12 weeks and averaged 168% increase in velocity over 12 Sprints. Most teams were less successful. The problem addressed in this paper is what to do about the 90% of Scrum teams that never deliver this capability.
Agile methodology—more specifically Scrum—is an increasingly popular approach to increasing the speed of software development while maintaining flexibility. Scrum works well when an entire team is collocated. Real-time communication happens between team members during daily Scrum meetings. But assume part of a team is operating in a different role, from a different location. Sound challenging? In this article, I’ll try to answer some common questions about user experience and Scrum by exploring the challenges a Development team faced when working with a separate UX team on a Scrum project. I’ll also provide recommendations for UX teams that are part of a Scrum team.
In 1993, at Easel Corporation in 1993, we we first applied the Scrum process to software development teams when we built the first object-oriented design and analysis (OOAD) tool that incorporated round-trip engineering. In a Smalltalk development environment, code was autogenerated from a graphic design tool, and any changes to the code from the Smalltalk integrated development environment (IDE) were immediately reflected back into design. Since the product was directed toward enterprise software development, we spent a lot of time analyzing best practices in software development methodologies.
This article aims to bring to the table a consolidated Agile Project Dashboard layout that could be easily maintained and updated by the Product Owner with day-to-day and well-known information provided by the team. He will be able to get stakeholder and management attention and support while providing an updated clear picture on the Project’s status.
When a team begins a project using the Scrum approach, one of the first questions that often arises is, "how long should our sprints be?" After the collective team understands what a sprint is and how Scrum works, several discussions on the topic usually ensue. This paper reviews the purpose of the Scrum timebox, the reason why two weeks has become the industry standard and some considerations for when another timebox may be appropriate for your particular situation.