Large Projects and Agile Techniques

Scrum for Large Projects

5 December 2013


SDLC and Agile

In Waterfall or other SDLC processes, a large project is defined as a multiyear effort. Scrum is one of the ways within Agile to execute such a project. If Agile/Scrum is adopted, it will be more successful than any other model. There are, of course, many questions about how to handle large projects using Scrum, and there are various opinions but no confirmed answers.

Scrum basics

Let's start with the first Scrum step and find detailed answers that might be helpful in making the appropriate decisions.

There are many terms used in Scrum:
  • Epic
  • User story
  • Task
  • Sprint coding
  • Sprint testing
  • Sprint features ready
The product owner and ScrumMaster work together to get those items done, with the stakeholder and product manager.

Sprint and user stories

For including a user story in a particular sprint:

Case True state Reasons
Can user stories be created without epic/requirements? No, they cannot. All user stories should belong to one of the epics.
Can features be ready without testing? No, they cannot. Features are part of every user story (US), in any sprint or any other existing US.
Can tasks be created without a complete US? No, they cannot. A complete US means US details, complete COS (conditions of satisfaction), and a clear understanding of the US. If any US is brought into the sprint without all of these, it will impact sprint velocity, resource use, and product owner effort as well.
Can coding be done without task creation? Maybe (yes/no) If a user story is complete and the COS is well defined, then yes -- otherwise no.
Can testing be done without coding during the sprint? No, it cannot.  

The overview of the details above means that the US, or a product backlog, needs to be created; the COS (conditions of satisfaction) needs to be defined; and the US should be completed (published) ahead of the task creation.

For example: The army needs to go on an operation, but first planning and trials must be completed. On decision day, it is a matter of the army executing the plan. Decision day begins when you bring the development team into the execution of the user story. Until then, it is just planning with the product owner, product manager, and stakeholder(s). In the above case, it will be more beneficial to use Scrum (user stories need to be written and published before the coding has begun).

Sprint planning points

  • A product owner, as part of Scrum practice, may have many business analysts who are equivalent to the product owner (proxy product owners). They will work with the product owner to create and validate the US and COS, which will help expedite user story creation and also, during the sprint, features validation.
  • Try to create small features and tie these features to prereleases.
  • Prerelease dates cannot be moved under any conditions.
  • Avoid creation of any additional user stories based on the velocity.
  • The team should always have at least six to eight sprints (two weeks per sprint).
  • Every team member can shadow or back up another and should be ready, within the team, to take over the sprint work.
  • To improve the sprint velocity, calculating it will help, along with planning resources capacity.
  • If the team sprint velocity is X and resource capacity is Y, after calculating resource capacity the ScrumMaster will get some number that equals overall velocity. This number (Z) will be more than team sprint velocity but cannot be less than team sprint velocity. Knowing these numbers will help the ScrumMaster plan the rest of work.
  • Last but not least, have 90-95 percent of user stories completed before decision day arrives.
Using these activities will help the department better plan resources and budget use.

Do's for Scrum and large projects

  • Each epic and user story should have some points (example: poker points) assigned to it.
  • User stories need to be maintained (written, updated, and deleted) by the product owner/product manager.
  • The ScrumMaster should talk to the product owner regarding adding any new user stories.
  • Assign small points to any user story that can be done during the sprint.
  • Every user story must have tasks.
  • Exploratory testing can be done during the sprint.
  • The product owner should sign off on every sprint.
  • Create a couple of sprints for UAT and production planning.
  • Changes in any completed user stories/COS should be done with the approval of the product manager and with additional poker points.

Don'ts for Scrum and large projects

  • During the sprint, avoid taking on new user stories.
  • Don't do any POC (proof of concept) work during the sprint.
  • The COS and user story details need to be clear, so the team can understand them easily and thoroughly.
  • Don't assigned big points to any user story.

Abbreviations

S.No. Abbreviation Description
1 COS Condition of satisfaction
2 US User story
3 UAT User acceptance testing
4 SM ScrumMaster
5 SDLC Software development life cycle



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Jessica Katz, CSM, 12/5/2013 12:10:32 PM
In all size projects Proof of Concept work is part of the effort. Why would doing that be a definitive "don't"? Isn't there a need for spike sprints to accommodate unexpected market changes?
Amit Sawhney, CSPO, 12/6/2013 3:35:32 AM
A Proof Of Concept itself may be a sprint/ part of sprint.
ABHISHEK KUMAR SRIVASTAVA, CSM,CSPO, 12/10/2013 5:53:57 AM
Great article Ravi! Presentation is really good.
There are a few points where if you can provide some more details would be good

"have 90-95 percent of user stories completed before decision day arrives."

"Don't do any POC (proof of concept) work during the sprint"

You must Login or Signup to comment.