Category: Rules

Scrum is easier than it seems, we’ll explain how in these 8 simple steps.

Print out the SSW 8 Steps to Scrum PDF and put it on your “War Room” wall.

1. Initial Meeting 

In the Initial Meeting, the Product Owner explains the product vision. The Developers think about the Architecture needed and how long they will need to come up with an estimate.

2. Backlog Construction 

The next step is Backlog Construction, also known as a Specification Review. The Developers propose a high-level software architecture and a to-do list called the Product Backlog. The required features are broken down into Product Backlog Items (PBIs for short).

These PBIs are estimated and, before a dollar figure is presented, a buffer is added for generic tasks such as DevOps, Testing, Bug Fixes, Project Management, etc.

This is also when the Product Owner 1st defines the Product Goal (aka the “why” of the project), although this can and should be refined throughout the project.

A quick note, there are only 3 roles in a Scrum Team, The Product Owner (the boss), the Scrum Master (a kind of project manager), and the Developers (who do the work).

3. Sprint Planning 

The Sprint Planning session is for the Developers to focus on the subset of the Product Backlog that they think they can complete in the next Sprint, (which is most commonly a 2-week time-box).

The Product Owner puts the PBIs into priority order and makes sure the top ones have enough detail to be worked on. The Developers then pulls PBIs from the top of the Backlog and commits to delivering as much as they forecast they can, in the coming Sprint.

The Developers and Product Owner together then define the Sprint goal, (aka the “why” of the Sprint).

4. Sprint 

The Developers work on features in priority order, having done a Daily Scrum and sending ‘Done’ emails once the ‘Definition of Done’ is met. A task board is often used. During this process, the team also refines items in the Product Backlog to ensure they conform to the ‘Definition of Ready’.

5. Product Increment 

Each Sprint is a potentially shippable Product Increment, and with good DevOps, including automation of deployment and testing, this can be done on a “PBI by PBI” basis. This means each feature worked on can be in production as soon as it is finished.

6. Product Feedback 

Product Feedback will then come in. Some will be bugs, and some will be small changes that can be added to the current Sprint. Other suggestions should be approved by the Product Owner and then added to the Product Backlog.

7. Sprint Review 

At the end of the Sprint, there is a Sprint Review, where the Developers demo or play done videos of the completed PBIs. The goal is for the Product Owner to understand the increment and to discuss the feedback to make the product better. This is the real measure of success of the Sprint.

8. Retrospective 

Lastly, there is the Sprint Retrospective, and this is the best part! The Scrum Team discusses what went well, what didn’t, and what to improve, always inspecting and adapting.

From here, another Sprint Planning session commences, and the wheel keeps turning, getting better and better with every revolution.

Source : https://www.ssw.com.au/rules/8-steps-to-scrum/  

---

Les rôles de Scrum

Developers : Les membres de l’équipe de développement qui sont responsables de la création du produit. Ils sont auto-organisés et interviennent dans tous les aspects du travail. 

Product Owner (PO) : Membre de l’équipe (généralement le client) responsable de définir et de prioriser le travail de l’équipe de développement en fonction de ses besoins. 

Scrum Master : Membre de l’équipe chargé de la bonne application de Scrum au sein de l’équipe de développement et de supprimer les obstacles qui entravent leur progression.  

You would never build a house without getting an architect to create a plan first. Usually, a specification process is done with the client before beginning work on a project.

As expected, it’s not realistic to fully understand the complexity of a client’s system, and give an accurate estimate after one brief meeting. For most business solutions, a few days are needed to obtain and document the requirements of the project’s stakeholders and, in turn, transform those ideas into a more detailed roadmap.

Deliverables

The deliverables for the Specification Review depend upon how large the application is and the time spent on the review. On completion of the Spec Review, the client will receive the following:

Requirement analysis

• An architectural roadmap recommending technical solutions
• A breakdown of the required software application into its core components, likely to include the approximate number of main features (e.g. forms, reports, etc.)
• An integration plan
• A deployment strategy
• An MVP (Minimum Viable Product) will be identified, as well as a wish list – requiring the client to set the priorities for the project by defining what is in and out of scope for the MVP
• A detailed list of ‘issues’ associated with the existing system which impact future development and maintenance
• Hardware and licensed software recommendations
• Mock-ups if required

Product Backlog

• A list of Product Backlog Items (PBIs) will be broken down based on the requirements analysis and the architectural design
• These PBIs will then be estimated

Ballpark $ estimates

• The estimated number of Sprints
• The estimated number of developers
• The estimated cost of the project

From wireframes to the final product

During the Spec Review process, we create wireframes to give the client a preview of the functionality and look of their proposed solution.

These wireframes are utilized in key stages of the development process:

• The developers talk to the client to gain a deeper understanding of their needs
• The developers design the wireframes for the client to envisage and sign off
• These wireframes are the direct reference developers use to work from 
• The developers send the product back to the client to test
• The developers showcase the final product with a Done Video

Let’s take a look at a real-world example.

These wireframes were created during the Spec Review and provided insight into the functionality of the client’s new search engine to both the client and the developer.

As you can see, the wireframes allow you to gain a ‘glimpse into the future’ and give the clearest possible depiction of the end product.

---

Source : ssw.com.au/rules/what-is-a-spec-review