Nexus Framework What is Nexus? Nexus is a framework that drives to the heart of scaling: cross-team dependencies and integration issues. It is an exoskeleton that rests on top of multiple Scrum Teams who work together to create an Integrated Increment. The result can be an effective development group of up to 100 people. How Do I Implement Nexus? You will need several techniques to bind the work of the Scrum Teams in your Nexus. We have developed or reformulated over 50 practices to help you launch and sustain a Nexus predictably. Manifesto for Agile Software Development AgileLib.Net Winston W. Royce From a talk Royce gave on August 10, 1990 Winston Walker Royce (August 15, 1929 – June 7, 1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, Texas. He was a pioneer in the field of software development,[1] known for his 1970 paper from which the Waterfall model for software development was mistakenly[2] drawn.[3] Biography[edit] Born in 1929, Royce entered the California Institute of Technology, where he received his BS in physics, his MS in aeronautical engineering and in 1959 his PhD in aeronautical engineering under Julian David Cole[4] with the thesis Transonic flow over a non-lifting, slender body of revolution. Royce had begun his career as Assistant Professor at the California Institute of Technology. Work[edit] Managing the development of large software systems[edit] The Waterfall model for software development is mistakenly attributed to Royce. The unmodified waterfall model. Software system engineering[edit] According to Richard H.
SSW TV - Videos by developers, for developers | .NET Training Agile Contracts: a Video Mini-Series Over the years I’ve built up a bit of knowledge about commercial contracts in an Agile environment. This is not something I really noticed until a few months ago when Laurence Bascle asked me to talk to the Agile4Agencies meetup group on just this subject. Laurence’s interest came from a piece I published in InfoQ a few years back - Agile Contract Options - but more recently I published “Dear Customer, the truth about IT projects” in the Agile Journal (which later became Agile Connection). Dear Customer has become something of an ever-green, I use it as a prologue in Xanpan and it regularly gets rediscovered and Tweeted about. So I sat down and compiled all my thinking into a presentation which I have now delivered twice and is available online. Now as some readers will be aware, this year I have been experimenting with video recordings as alternatives to the written word. I’ve broken the Agile Contracts presentation into 11 short recordings and published them on YouTube.
Scrum Role Playing Scrum is very explicit in its clarification of roles and responsibilities. Scrum has only three roles; together they cover the responsibilities needed to ensure a successful project. The Product Owner represents the customer and sets the vision, goals and priorities of the project. Almost anyone who has been on a Scrum project has noticed the issues that can arise when one Scrum team member wears two hats (for instance, when one person plays both the role of ScrumMaster and the role of developer or when one person plays Product Owner and developer). Another less-than-ideal scenario is having one person play the roles of ScrumMaster and Product Owner. While none of the problems in the above scenarios is insurmountable, arguably the most anxiety-inducing and uncommon dual-role is the combination of ScrumMaster and Product Owner. The developers were happy for Ben to take on the role (perhaps because none were too keen on being ScrumMaster themselves!)
User Stories and User Story Examples by Mike Cohn What is a user story? 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. Can you show some user story examples? One of the benefits of agile user stories is that they can be written at varying levels of detail. As a user, I can backup my entire hard drive. Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. As a power user, I can specify files or folders to backup based on file size, date created and date modified. How is detail added to user stories? Detail can be added to user stories in two ways:
AgileLib.Net ✭New feature: AgileLib Logbooks — read more here Agile excellence requires continuous learning and exploration. Many resources exist to support this journey—but an equal number may hinder it. AgileLib.Net is a library of agile-related resources built by agile practitioners for agile practitioners. Participating agilists maintain personal lists of recommendations, and the visitor can browse these lists, view resources by category or level of experience, or search for specific terms. The aim of this website is to get you off this website—onto bookseller sites, youtube, twitter, blogs, interactive forums, live meetups and anywhere else where you can learn more about the craft of Agile software development, and its related fields. Contribute Content Please contribute to our knowledge base by recommending your favorite agile (or related) resources—your own or others'. Become a Sponsor We invite Agile-focused organizations who value excellence through community to sponsor this website.
Agile Story Card Templates - SolutionsIQ Help Drive Consistency Simplicity – maximizing the amount of work not done – is an essential aspect of achieving organizational agility, and also happens to be one of the twelve Agile Principles behind the Agile Manifesto. A quick way to make your team’s space a little more simple is by having consistent looking Story Cards up on the wall. Why waste time trying to remember the story’s name – always have it in the same place. What do they look like? What’s the best way to use the cards? Here are the primary guidelines: Story NameStory TypeStory SizeAcceptance Criteria (on back)Comments You can also easily track: PriorityKano AnalysisDependenciesTargeted ReleaseIteration CommittedDay Started & Day Finished Why is the back upside down? It may seem a little odd, but we’re Agile Practitioners and do this stuff every day and trust us – it can get annoying to always have to take a card off the wall to read your Acceptance Criteria. Here are a few other ways to use the SolutionsIQ Story Card Template.
The Burn-Down Chart: An Effective Planning and Tracking Tool Burn-downs charts are among the most common sprint tracking mechanisms used by Agile practitioners. Though their application and usage varies (some plot a burn-down chart using story points, whereas others use task count), plotting burn-down using effort remaining is the most effective and efficient way of using burn-down charts. This article looks at creating and updating a burn-down chart using the effort-remaining approach, interpreting burn-down under different scenarios, and examining common mistakes to avoid while using burn-downs. How to create a burn-down chart The first step is to have a task breakdown in place. Figure 1 The Y axis depicts total hours in the sprint (420 hours), which should be completed by the end of the sprint. Updating the burn-down chart Each member picks up tasks from the task breakdown and works on them. As we progress during the sprint, the burn-down will look like this: Figure 2 Interpreting the burn-down chart Type 1: Sprint commitment met (smooth flow)