User Stories are part of an Agile approach that helps shift the focus from writing about requirements to talking about them. All Agile User Stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
User Stories provide a light-weight approach to managing requirements for a system. User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
User Stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
Read More »
Understanding the Stages of Team Formation
Forming a team takes time, and members often go through recognizable stages as they change from being a collection of strangers to a united group with common goals. Bruce Tuckman’s Forming, Storming, Norming, and Performing model describes these stages. When you understand it, you can help your new team become effective more quickly.
The Forming – Storming – Norming – Performing model of group development was first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results. This model has become the basis for subsequent models. The Tuckman Model states that there are four stages of project team development that are inevitable in order for a team to reach a point where they are functioning effectively together and delivering high quality results. The graph below depicts how a team’s effectiveness varies depending on their state.
Read More »
T-Shaped People are individuals who are experts or specialists in a core skill but also have a broad range of skills in other areas. A T-Shaped Person combines the broad level of skills and knowledge (the top horizontal part of the T) with specialist skills in a specific functional area (the bottom, vertical part of the T). They are not generalists because they have a specific core area of expertise but are often also referred to as Generalizing Specialists as well as T-Shaped People. A Generalizing Specialist does one kind of job very well and some other jobs adequately.
Read More »
Organizations that have diligently applied Scrum are experiencing a different reality.
These organizations are repeatedly delighting their customers by giving them what they really want, not just the features they might have specified on the first day when they knew the least about their true needs. They are also seeing an improved return on investment by delivering smaller, more frequent releases. And, by relentlessly exposing organizational dysfunction and waste, these organizations are able to reduce costs.
Scrum’s focus on delivering working, integrated, tested, business-valuable features each iteration leads to results being delivered fast. Scrum is also well suited to help organizations succeed in a complex world where they must quickly adapt based on the interconnected actions of competitors, customers, users, regulatory bodies, and other stakeholders. And Scrum provides more joy for all participants. Not only are customers delighted, but also the people doing the work actually enjoy it! They enjoy frequent and meaningful collaboration, leading to improved interpersonal relationships and greater mutual trust among team members.
Read More »
At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements.
The Sprint Retrospective is one of the most important and least appreciated practices in the Scrum framework. It is important because it gives teams the chance to customize Scrum to their unique circumstances. It is under-appreciated because some people have a misguided view that it takes time away from doing “real” design, build, and test work.
The Sprint Retrospective is a crucial contributor to the continuous improvement that Scrum offers. Scrum teams hold Retrospectives each and every sprint, allowing teams to take advantage of insights and data before they are lost. Because a Scrum Team meets at the end of each Sprint to inspect and adapt its Scrum process, it can apply early and incremental learning throughout the development process and thereby significantly affect the outcome of the project.
Read More »
Near the end of the Sprint, the team conducts two important inspect-and-adapt activities: the Sprint Review and the Sprint Retrospective. The Sprint Review focuses on the product itself. The Sprint Retrospective, on the other hand, looks at the process the team is using to build the product.
During Sprint Planning we plan the work. During Sprint Execution we do the work. During Sprint Review we inspect (and adapt) the result of the work – the Potentially
Shippable Product Increment. The Sprint Review occurs near the end of each Sprint cycle, just after Sprint Execution and just before – or occasionally after – the Sprint Retrospective.
The Sprint Review gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The Sprint Review provides a transparent look at the current state of the product, including any inconvenient truths. It is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities.
Demonstrates what was achieved in the Sprint and collect feedback
Whole team participates
Invite anyone and everyone
Read More »
In Scrum, work is confined to a regular, repeatable work cycle, known as a Sprint or Iteration. Scrum Sprints are fixed intervals, ranging from one week to one month with preference to shorter periods. Working within the boundaries of such an accelerated time-frame, the team would only be able to build the most essential functionality.
A Release is typically composed of multiple Sprints, each of which delivers customer or user value. Every Sprint begins with Sprint Planning, a time when the Scrum Team gathers to agree on a Sprint Goal and determine what it can deliver during the forthcoming Sprint.
Sprint Execution accounts for the majority of time during a Sprint. It begins after Sprint Planning and ends when the Sprint Review starts. On a two-week-long Sprint, Sprint Execution might account for about eight out of the ten days.
Sprint Execution is the work the Scrum Team performs to meet the Sprint Goal. During the Sprint, the Development Team self-organizes to produce a Product Increment in accord with the Sprint Backlog, as determined during Sprint Planning. Self-organizing means that the team responsibly produces the Product Increment in accord with all the organization’s standards, according to the Definition of Done, and that the Development Team determines just how to go about that.
The Scrum Master participates as the coach, facilitator, and impediment remover, doing whatever is possible to help the team be successful. The Scrum Master doesn’t assign work to the team or tell the team how to do the work. A self-organizing team figures these things out for itself.
The Product Owner must be available during sprint execution to answer clarifying questions, to review intermediate work and provide feedback to the team, to discuss adjustments to the Sprint Goal if conditions warrant, and to verify that the acceptance criteria of Product Backlog Items have been met.
Read More »